Am Freitag, den 23.03.2007, 08:41 -0400 schrieb Jim Fulton:
> 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. :(

Ack. :( 

I'd be fine with dropping an egg-based release though. We still have
everything in place to make a zpkg-based release happen as before.

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

Yes. Both in the wiki ( and on launchpad.

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

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

Just to make this explicit: we've gotta stick with the version numbers
that we gave out already, right?

> 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 agree here as well. Does that mean we will not advertise the
availability of the Zope 3.4 code as eggs from the release information?

> > 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 is too uncontrolled.

We saw what happened when I started using it at the sprint. ;) Low-tech
is good, but at least some of the current limitations are impractical


gocept gmbh & co. kg - forsterstra├če 29 - 06112 halle/saale - germany - [EMAIL PROTECTED] - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Zope3-dev mailing list

Reply via email to