[Zope-dev] Re: [Zope3-dev] December release post-mortem
Jim Fulton
jim at zope.com
Wed Jan 18 19:09:01 EST 2006
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
More information about the Zope-Dev
mailing list