GeoServer : GSIP 77 - Time boxed release model
This page last changed on Sep 27, 2012 by aaime.
Switching releases to a time boxed release model with clear indications of what can be done when to get out more releases, more often, and with good preticability of what can be done when.
The time boxed release model is meant to start opearting with the GeoServer 2.2.0 final release.
Choose one of: Under Discussion, In Progress, Completed, Rejected, Deferred
The current release model is based on resource availability (e.g. resources to push out the release). This is due to the time it took to make a release, which has now been addressed via the automation scripts that drastically reduce the time needed to make a release.
The current model results in unpredictable releases, even on the stable series (e.g., 2.1.3 released in December and 2.1.4 released in June) and very long times between major ones (usually between one and one and a half year).
The automation scripts lowered significantly the time needed to make a release, meaning we can switch to a more pretictable time boxed model
GeoTools and GeoServer have had a tight relationship for a long time, so that most (but not all) GeoTools releases are actually tied to a GeoServer release.
So it would make sense to have the same time boxed model work for GeoTools
Of couse all the stability preserving rules stated in the proposal also make sense only if they are applied on GeoTools as well, this means the above proposal will have to be voted and accepted by both control commitees to be well working.
Switch to a time boxed release model where released are made based on a predictable schedule, and identify what can be done on the various branches at a given time.
Here is an example of the proposed model and how it could play out (precise dates are fictional, not meant to be used in practice, the actual dates will be set in stone once we start rolling the new release model):
Time wise, the model proposes monthly based releases and a six month relase cycle.
Every month, on the same day, a new release is issued using whatever revision of GeoServer/Geotools passed the last CITE tests.
The release is meant to improve upon the previous release in both functionality and stability, so unless the control committee determines reasons to block the release it will happen regardless of what bug reports are in Jira (pending resourcing, they can be fixed in the next release that comes out one month later).
At every point in time there are two branches, a stable branch and a trunk, with just one month every six where there are three active branches (nothing prevents developers willing to keep the stable series up longer working there if they wish to, it's just not expected anymore).
The stable branch is meant for bug fixes and new features that do not affect the GeoServer API or significaly affect the stability.
Trunk lifecycle is divided in two periodds:
Trunk and stable branches see three months of parallel releases as trunk is getting stabilized. At the end of the last month of the green area a first beta is released, which sets the beginning of the hardening and allows the user base to start kicking trunk tires.
One month later another beta is released and this starts the final period of the major release, in which a RC is pushed out every two weeks until no major issues remain, at which point the RC is renamed into final and the stable/trunk release cycle starts again.
The latter is the only portion of the release cycle which is not fully predictable, as we don't want to release a new stable series with blocker issues.
A new trunk is cut when the first RC release is done. This means there will be one month of hardening in which no trunk activity is planned.
With shorter times between one major release and the next attention is drawn to proposal evaluation.
In particular, proposals should point out even better than before how the resourcing is going to be ensured, and how much time the proposal will take before completion.
In case a proposal is late in the game and there is a tangible risk of not being completed in time there should be either a plan to roll it back with little damage, or should be deferred directly to the next major release.
Switching the releases to a time based model should also allow planning in advance for the resources (people) needed to make a release, with a time based rotation.
While the PSC is going to be able to vote and override the committing guidelines, it is still good to have some reference and default of what can be done or not done in the various branches.
Hardening mode, and by extension, stable and trunk, can take any of the following:
Stable branch can take in addition the following:
Stable branch changes that can get in with a solid PSC/PMC vote (e.g., no doubts or concerns about them):
Trunk in "green" mode can take everything, of course large changes are still subject to proposals and reviews.
This section should contain feedback provided by PSC/PMC members who may have a problem with the proposal.
No backwards compatibility issues known.
List of committee members, and their affiliation to GeoTools/GeoServer steering/management commitees:
Andrea Aime (gt/gs): +1
Initial discussion on the mailing list: http://osgeo-org.1560.n6.nabble.com/Discussing-a-switch-to-a-time-boxed-release-model-td4943722.html#a4955793
|Document generated by Confluence on May 14, 2014 23:00|