[Zope3-dev] Zope 3.4 release

[Jim Fulton]

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

> Christian Theune wrote:
>
>> Hi,
>>
>> 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:
>> http://wiki.zope.org/zope3/DefiningZope34Release
>>
>> 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. :(

> Because,
>  - 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:

   http://wiki.zope.org/zope3/Downloads

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

Yup.

> 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

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