This page last changed on Jul 30, 2009 by aaime.

Overview

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

Proposed By

Andrea Aime

Assigned to Release

The release that this proposal will be implemented for.

State

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

Motivation

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

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

Feedback

  • 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.

Backwards Compatibility

No backwards compatibility issues

Voting

Andrea Aime: +1
Simone Giannecchini: +1
Alessio Fabiani: +1
Justin Deoliveira: +1
[~jgarnett]:
[~roba]:

[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|]

Document generated by Confluence on May 14, 2014 23:00