Andreas Jung wrote:
--On 12. September 2006 13:06:05 +0200 Martijn Faassen <faassen@infrae.com> wrote:
Andreas Jung wrote:
--On 12. September 2006 12:28:10 +0200 Martijn Faassen <faassen@infrae.com> wrote: [snip]
Anyway, if the main thing holding up *this* release is bugfixes, doing a new release in 3 months shouldn't be a problem, as after all, we've already fixed those bugs this time around. :)
3 month for a new release cycle is just too short. We should not follow the IMO broken concept of "release early, release often" but to follow "release regular, release solid". At least me I refuse to release something just for the sake of making a release at a certain date.
The current CHANGES.txt from the trunk just lists one new feature (added by myself). That's does not deserve a major release.
It's the nature of time-based releases, though. If nobody does anything in 6 months, does that mean we won't have a release at all? Zope 2 also includes Zope 3, so that might help feature-wise.
The goal is not release early, release often, but to get back to our regular release schedule. After all, we already had 3 months to add code to Zope 2 and Zope 3 trunk that will be included in the next release, as I believe they branched at the time.
Not much happened during the three month or I did I miss something?
So imagine we had done the release in june as we planned and everything else would be the same. Would that mean we would've canceled the next release, as we'd only have 1 new feature?
Could you explain the reasons for the coming 3 months being too short in this particular case? What features are we adding to Zope 2 or Zope 3 that make it too short and thus would result in a not-solid-enough release?
We just don't have nothing new right now.
That could then not be affecting the solidity of the release, just how interesting the release is. :)
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.
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? Regards, Martijn