Hi. Martijn Faassen wrote:
Andreas Jung wrote:
--On 12. September 2006 13:06:05 +0200 Martijn Faassen <faassen@infrae.com> wrote:
Another point with this whole half-yr release cycle: we're going to confuse more and more professional users about which Zope version to use for what. 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 definitely 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 the 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 Plone. 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 release cycle.
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. Hanno