[Zope-dev] Re: [Zope3-dev] December release post-mortem

[Jim Fulton]

Martijn Faassen wrote:
...

> How do you assemble releases 'from releases'? I'm not sure I understand 
> that. You mean make a Zope 2 release using a Zope 3 release?

No, I mean using eggs.  Zope should be broken into separate projects
with their own eggs.  A Zope release might just be an egg with dependencies.
Or it might just be a collection of eggs.

> You know my position concerning the repository and the release; I'd 
> prefer them to be kept as similar as possible to simplify the release 
> process. I hope we can go in that direction. It also makes things more 
> predictable to developers. We noticed that some Zope 3 packages weren't 
> packaged into Zope 2 after the release, even though in a developer's 
> sandbox of Zope 2 they were there.

Right. If eggs work out, then a respository check out will be a lot smaller,
but will download needed eggs.  This would be a replacement of the
use of externals we have now.

> As a side issue: From the perspective of Five, it is beneficial to have 
> as much Zope 3 code included into Zope 2 releases, as that gives us an 
> opportunity to start using this functionality right away, exposing it to 
> Zope 2, without waiting for a new release.

Understand though that there is nothing like a backward compatibility
promise for something that hasn't been released.

> [snip]
> 
>> We have begun to see Zope 3 decomposed into separate projects knit
>> together via svn:externals.  I'd like to see that trend continue and
>> to perhaps switch to making the knitting process use eggs,  I'd like
>> to leverage eggs to make the release process much simpler.  It should
>> be easy for people to make releases so that there could easily be
>> multiple distributions aimed at different needs and expectations.
> 
> 
> I'll repeat here that I think there's much value in trying to keep the 
> mapping of the SVN repository very similar to what is actually released. 

I think I understand where you are coming from.

>   (If you're interested I can try to explain some of my thinking a bit 
> deeply.) Eggs are a nice distribution mechanism, but I'd also want the 
> knitting process to work for a SVN checkout -- developers working with 
> SVN need to be very easily work with a 'knitted' version, so perhaps 
> svn:externals will remain a valuable tool.

Assuming that eggs fullfill their promise, I think I'd
rather use eggs than externals.

>> As part of this decomposition, we need to make zope.app much smaller.
>>  Early in Zope 3 development, I proposed a simple rule for
>> organization of the repository: Anything that depended on zope.app
>> went in zope.app. Anything else went in zope.  If there was doubt,
>> put it in zope.app.  I think that served us well at the time, but I
>> think we've moved beyond that,  I'd like to migrate most of zope.app
>> elsewhere.  Zope 2.10 should not include zope.app.
> 
> 
> This worries me; Five is currently using massive quantities of code in 
> zope.app, and as expressed above, I value Five having access to 
> potentially all Zope 3 code that's in a Zope 3 release.

The code that Five is using will still be available, but it will be
somewhere else (with necessary backward compatibility hacks).

Jim
-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org