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.


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 much smaller.
 Early in Zope 3 development, I proposed a simple rule for
organization of the repository: Anything that depended on
went in Anything else went in zope.  If there was doubt,
put it in  I think that served us well at the time, but I
think we've moved beyond that,  I'd like to migrate most of
elsewhere.  Zope 2.10 should not include

This worries me; Five is currently using massive quantities of code in, 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 Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to