On Mar 23, 2007, at 4:12 AM, Baiju M wrote:

Christian Theune wrote:


we (Jim, Nathan, Michael and me) did some planning on how we're going to release Zope 3.4 and the future Zope 3 releases that are based on eggs.

I tried to catch up and did my writing here:

There is also a project in the repository in Zope3.buildout that tries
to implement the proposal and is a work in progress that doesn't work
right now.

I think we need not to mimic the zpkg based release for 3.4, rather we should use zpkg for this release also.

Minor note:

No one is talking about "mimicking" a zpkg release. The plan was to switch from using zpkg to eggs to create releases. Unfortunately, I don't think we have time to do this now, although I think we are getting close. :(

- there is no particular advantage for mimicking zpkg based release using zc.buildout

If the purpose of the release is purely political, then I agree.

 - we are gradually moving towards an egg based releases
 - applications are better to build using zc.buildout
- our 3.4 alpha 1 release date is approaching, we follow time- based release !

Is there a roadmap somewhere?

It seems that something should be recorded at:


Who is in charge of the 3.4 release?

(And our policy is to drop a feature, if it's not ready at time, is it?)


In addition to this zpkg based release, we can release all eggs (as mentioned in the proposal) and make it
available for download from a location.

I think these 2 activities should not be linked. Perhaps this should be a goal of 3.5 release.

I want to get to the point where the packages have their own release cycles independent of Zope 3 releases. For example, I want to stop giving eggs 3.x releases numbers just because the package
was included in a 3.x release.

Assuming that someone decides to move forward with 3.4 release sans eggification, then I'd like to decouple the 3.4 release from the eggification efforts.

I think we are going to stop current way of releasing Zope 3 sooner or later, so we should advocate the use of
eggs and zc.buildout for building and deploying Zope 3 applications.

Yup, but I don't think we're there yet. What we have now, thanks to your effort and efforts of others, is a proof of concept. There are lots of issues that need to be addressed before we can move this effort off of the bleeding edge, including:

- We need more mature eggs that we have now. Many of our eggs aren't ready for independent release. Dependencies are a mess and I think it's going to take a good bit of work to clean the dependencies up.

- We need to figure out what the distribution mechanism will be.

- PyPI in it's current form is less than ideal, in at least a couple of ways:

      - It is too slow.

- It's default policy of hiding old distributions makes it impractical to specify specific distributions in buildouts for repeatability.

Both of these problems can be fixed, but it will take a bit of effort. I have necessary access, but not sufficient time. I'm most worried about support for old versions and I think this can be addressed through a planned setuptools change.

   - I worry that download.zope.com/distribution is too uncontrolled.


Jim Fulton                      mailto:[EMAIL PROTECTED]                Python 
CTO                             (540) 361-1714                  
Zope Corporation        http://www.zope.com             http://www.zope.org

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

Reply via email to