[Zope3-dev] RFC: Release cycles

[Jim Fulton]

Philipp von Weitershausen wrote:
...

> Many things have been planned for X3.1. Stephan has already tackled one of the 
> big tasks, ImplementViewsAsAdapters; other minor improvements that didn't make 
> it into X3.0 are also already sitting in trunk or about to be committed. 
> However, other things that were originally planned for X3.1 have not even been 
> thought through properly (correct me if I'm wrong), like local configuration 
> through ZCML. I see no reason whatsoever holding off X3.1 for them; why 
> couldn't they go into X3.2, X3.3, etc., when they're ready?

No reason at all.

> I suggest to adopt a release management similar to Debian's (except that they 
> take ages for new releases which we don't want). A short period of time after a 
> certain version is released (e.g. X3.0), the next version (e.g. X3.1) should be 
> branched off from the trunk. At that time the branch is under a feature freeze 
> like the X3.0 branch was when it was branched off. The trunk will be open for 
> new features as usual.

Could you describe the benefit you think this provides?

> What this proposal is not
> 
> This is purely a proposal regarding when to branch, when to release and what to 
> put in which branch. I'm NOT proposing to change any of the quality assurance 
> measurements we've been taking, including the actual speed of development on 
> certain features. Taking time to find use-cases, write proposals, implement and 
> test features is still important! My concern is just that features needing this 
> much time would hold off releases of otherwise releasable features.
> 
> I'm also not proposing to set a specific time period that a release cycle 
> should take. Quality code takes time and that's ok.

More importantly, it takes volunteers.

 > It is all about getting
> already implemented features out. However, I imagine that X3 releases could 
> happen every 6 months or so, but that's just an estimate.
> 
> Advantages
> 
>  - shorter release cycles
> 
>  - new features appear in releases quicker
> 
>  - contributors get to use features that they implemented earlier
> 
>  - changesets from one version to another are smaller, making transitions
>    smoother; that would also be a lot easier on 3rd party developers who
>    need to adjust their software when new versions are released.
> 
>  - legacy code for backward compatability can be removed sooner
> 
> Disadvantages
> 
>  - more overhead for the developers (though I think this is marginal if at all
>    existant; I expect not more than two branches [trunk and to-be-released
>    branch] to be active at a time, so it'd be just like now.)

It is hardly marginal.  It is a significant expense.

>  - probably need a release manager

And people willing to work on the releases. This is a lot of effort.

> 
> Those who are involved into Plone I'd like to remind about the 2.0 release. 
> Initially a 1.1 release was planned after 2.0. It provided a relatively small 
> set of improvements. Before someone could put his foot down, lots of stuff was 
> checked in and 1.1 started to blow up. Initially a 1.1 release was planned for 
> September 2003; 6 months later, in March 2004, it was released, but as 2.0 
> because of the many additions. Many people who based their business on Plone 
> and needed something like 1.1 in late 2003 (including me) critized the release 
> management. Everyone learned their lesson and Plone now has an official release 
> manager.
> 
> Another good example from Zope's own history is be the release of 2.7, though I 
> think this one took so long for several different reasons (I frankly don't 
> remember). Fact is that now with Andreas being the release manager, 2.7 bugfix 
> releases are popping out regularly...

The bottom line is that releases take a lot of effort to release and manage.

As long as there are enough volunteers, we can have more releases, but don't
assume that there will be enough.

I know that Fred and I don't have time to work on a 3.1 any time soon.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org