GeoServer : GSIP 27 - Long freeze handling procedures
This page last changed on Jul 30, 2009 by aaime.
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
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:
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:
No backwards compatibility issues
|Document generated by Confluence on May 14, 2014 23:00|