Martijn Faassen wrote:
> Andreas Jung wrote:
>> --On 12. September 2006 13:06:05 +0200 Martijn Faassen
>> <[EMAIL PROTECTED]> wrote:
>> Another point with this whole half-yr release cycle: we're going to
>> more and more professional users about which Zope version to use for
>> I've heard from my major customer but also from other ppl. IN December
>> we would have *three* maintained versions 2.9, 2.10 and 2.11. We
>> can't deprecate Zope 2.9 in December because this version is required
>> by Plone 2.5. Plone 2.5 was just released and ppl just start to migrate
>> from Plone 2.1 to Plone 2.5. We have the burden maintain Zope 2.9 for
>> mid-future. So my personal impression right now is: we're flooding the
>> community with new major releases and the community does not adapt those
>> releases. My theory: a major part of the ppl running Zope are running
>> on top of Zope...so with have to deal with this fact somehow.
As Plone was mentioned as a an argument for scheduling releases, I
should probably explain our current release strategy.
Similar to Zope 2.8 we had a Plone 2.1 release that took more than 18
months to complete. After that we aimed for the next release (called
2.5) to ship six month after that. Here we tried to copy the new Zope
release schedule. But while we tried hard to get a release out in time,
we did not succeed with it and ended up with a 9 month release cycle.
Now we again aimed for a release six month after 2.5 but we had to
adjust our roadmap already and right now we aim for another 9 month
> That is a good argument for lengthening the release cycle. (as opposed
> to say, people will fix more bugs if the release cycle is longer)
> What do you think about a 9 month release cycle?
Based on the Plone experience I think this is a good compromise, between
release often and stable releases.
Zope3-dev mailing list