[Zope-dev] Release schedule for Zope 2.11/3.4?

Martijn Faassen faassen at infrae.com
Tue Sep 12 08:44:11 EDT 2006


Andreas Jung wrote:
> --On 12. September 2006 13:06:05 +0200 Martijn Faassen 
> <faassen at infrae.com> wrote:
> 
>> Andreas Jung wrote:
>>> --On 12. September 2006 12:28:10 +0200 Martijn Faassen
>>> <faassen at 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


More information about the Zope-Dev mailing list