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:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
