Andreas Jung wrote:
--On 12. September 2006 13:06:05 +0200 Martijn Faassen <[EMAIL PROTECTED]> wrote:

Andreas Jung wrote:
--On 12. September 2006 12:28:10 +0200 Martijn Faassen
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

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 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?


Zope3-dev mailing list

Reply via email to