For every major release we have a long running freeze period that prevents every activity on the stable branch for a long period, making it harder development on the same branch. This needs to be addressed to allow small features and non critical bug fixes to be attended without un-nedeeded delays Motivation Proposal Backwards Compatability Feedback Voting Links

Andrea Aime

The release that this proposal will be implemented for.

Choose one of: Under Discussion, In Progress, Completed, Rejected, Deferred

Explain in decent detail why you are putting forth the proposal.

This proposal is a procedure related one, it does not affect the code, but the way we deal with branches during long RC periods.

Once a year we release a major GeoServer version. This requires a sustained development time that culminates in the first Release Candidate.

The first RC marks the moment in which access to the stable branch is restricted: from that moment on, only critical bug fixes can come in. The very nature of the release candidate process implies a long freeze:

• developers need to wait for user’s feedback, leaving at least one week between on RC and the next one
• only critical bug fixes are allowed on the stable branch

This basically means a handful of developers can deal with RC phase, leaving all others hands free. New heavy developments take of course place on trunk, but small new features, non critical and possibly controversial bug fixes still need a place to be developed.

Doing so on trunk is problematic, as a lot of patches grow that need to be backported pile up, and a month or more can pass before the stable branch is again open for business.

We propose to change the way in which the RC phase is dealt with as follows:

• when the first RC is cut, a new branch, a.b.0-rc, is created, where only critical bug fixes can be commited. All such bug fixes must be immediately ported to a.b.x and trunk.
• the a.b.x branch is open for business as usual, that is, for bug fixes and small new features
• when the a.b.0 final release is made, the rc branch is closed

• This approach does increase the development overhead: this is true for the developers committing patches on the rc branch, and this is why only critical (so, few) bug fixes are allowed on it. It also means RC must be cut when the developers are really confident the release is of good quality to start with. On the other side, all other developers work with less overhead because they don’t have to annotate all the patches in progress, the revision number at which the commit occurred on trunk, waiting to backport, or to create a custom branch to keep on working on their stuff
• \Does this mean the a.b.x branch is open for whatever change?: no, it means it has to be treated as usual, only bug fixes and changes that do not critically affect the whole GeoServer or the stability of core modules are accepted. Example of such new features are new output formats, new services, new restlets.

No backwards compatibility issues

Andrea Aime: +1 Simone Giannecchini: +1 Alessio Fabiani: +1 Justin Deoliveira: +1 Jody Garnett: Rob Atkinson:

JIRA Task Email/IRC Discussion [http://www.nabble.com/Prolonged-freezes-and-dealing-with-gt2-td20087000.html] [http://geoserver.org/display/GEOS/2008/10/21/IRC+logs%2C+October+21]

Wiki Page