Andreas Jung wrote:

My point is: we are adding a lot of new code to the Zope 2 core - it does not matter if there is a tight or a loose coupling between Z2 and Z3 - and calling it beta.


My fear is that we are running into the same release problems as with
the Plone 2.0 release (lots of development and changes during the
beta phase).

I think it does matter that we're not creating new code, but loosely integrating code that already exists, used, and, mostly, has already been released. I think that's quite different from what you describe was a problem with the Plone 2.0 release.

No debate with doing an alpha, though. There are likely to be more kinks to be worked out indeed.

My suggestion: let's make an Zope 2.8 alpha 2 in the first week of April and let us nail down a release date for beta 1 (in early May).
So there is enough time for interested people to test the Z3 integration and for others to fix outstanding issues in the Zope 2 core. This gives everyone (I have the Plone, CPS, Silva communities in mind) the possibility to check out if there is something missing in Zope 2.8 *before* we are going into a *short* beta release cycle with hopefully a final version in Q2. Any comments?

I'd prefer a shorter cycle, with an alpha 2 this month, a beta in april, and a release at the latest in may. I would also very much like to have a release date set and committed to. I don't like to hear "hopefully a final version in Q2" and such estimates in relation to Zope releases; it almost *invites* further delays.

We must face that in practice most testing by the wider community will happen *after* the release anyway. I also would like to add that core Plone hackers, core Silva hackers, and core CPS hackers were all at the sprint in Paris and *already* did significant testing. In addition, both Nuxeo and Infrae are using Five in a number of a active development projects at the moment, and Enfold has in fact already been in *production* with Five since last year. This stuff is being tested.

I don't expect people will have a lot of time to do extensive testing after the sprint, anyhow. Giving people more time to do testing won't actually encourage them doing anything, as they can always wait until later. Setting release dates is the best bet at getting people to do it. Especially if we show we're committed.

I would also like to refer you to the Linux kernel, where release candidates are rarely tested, and the real bugs come out with production releases. I think that's also a reality for Zope.

The core Plone, Silva and CPS developers present at the sprint also expressed a strong preference for getting this into production quickly.

There will be bugs in Zope 2.8, but a Zope 2.8.1 release should be relatively easily made if that's the case.

There are some resources available to make this release happen on time. I'll commit a bit of my time, and I trust the others who worked on this at the sprint will chip in as well.


Zope-Dev maillist -
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to