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 (wiki.zope.org/zope3) and on launchpad. > It seems that something should be recorded at: > > http://wiki.zope.org/zope3/Downloads > > Who is in charge of the 3.4 release? /me > > (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 download.zope.com/distribution 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 unfortunately. Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Zope3-dev mailing list [email protected] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
