Jim Fulton wrote:
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.

Ah, makes sense. A 'meta-package', so to speak. Works well in Debian, so I think that's an interesting pattern to follow. As long as we can do those micro releases quickly -- the problem is that Zope 3 is one project, and we want one communication channel, as we simply don't have enough people otherwise. From another perspective it's many projects, though.

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.

A risk here is that if I find a bug in package X, I can't easily track it into package Y and fix it there, as package Y is an egg. The current system doesn't have this problem.

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.

Yes, but Zope 2 included *less* than Zope 3 in the most recent release, and I'd like *all* packages that are in a Zope 3 release to be available in a Zope 2 release. I.e. Five doesn't want packages that aren't in a Zope 3 release, but not less either.

(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.

Sure, but see the risk I mentioned earlier in this mail.

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).

As long as Zope 2.10 contains all packages in Zope 3.


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to