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.

Andrea Aime

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). It also increases pressure to get significant new features in the stable series, or to try to add major changes on trunk close to the first beta release.

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

• Timed Release

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. A PSC vote (with eventual proposal) can be called in case a significant new feature or change needs to be back ported to the stable branch overriding the above definition of stable branch. If, for any reason, a release is delayed the next release will be rescheduled 30 days after the last release (another option is to keep the next one shorter and respect the fixed dates, please discuss).

Trunk lifecycle is divided in two periodds:

• The green one is meant to be free for stability undermining changes (even significant). Those changes needs to be voted as GSIP anyways to ensure, as usual, resourcing checks, API consistency and community review.
• The red one is meant to harden the trunk and move towards a stable release, so nothing undermining stability is meant to be committed during such period.

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. The switch to Git will make this not much of a problem for those that need to do significant new develpoment, and is meant to push as many developers as possible into participating into the hardening portion.

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. Proposals for larger changes must ensure that they land on trunk in the green zone and that they are completed (bug fixes aside) before the hardening starts.

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 needed to make a release, with a time based rotation. In practice, if we want, we could plan in advance the next six months assignign in advance a resource to each release, allowing people to plan well in advance and ensure they have time to dedicate to the release when the day to do it comes.

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:

• bug fixes
• documentation improvements
• new plugins contributed as community or extension modules (with a cautionary note that during hardening the attention should be concentrated as much as possible on getting the new release stable)

Stable branch can take in addition the following:

• new minor core functionality (e.g. new output format,
• new API that we can commit to for a long period of time, provided it’s not a change to existing API unless the PSC votes otherwise). GeoTools wise things are easy, we have an API module, new classes/interfaces can be added there, but existing ones cannot be changed. GeoServer is not a library, so defining API can be hard, but any class that can be used by pluggable extension points should be changed with care, especially so in a stable series. Geotools

Stable branch changes that can get in with a solid PSC/PMC vote (e.g., no doubts or concerns about them):

• promotion of extensions to core (requires GSIP anyways)
• core changes that are unlikely to affect the stability of the upcoming release (cautious with those, if the PSC is ok better land them right after a release to get as a large window for testing as possible)
• backport of larger changes that have proven to be working well on trunk for an extended period of time

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.

• Update the GeoTools developer guide with the contents of this proposal
• Update the GeoServer developer guide with the contents of this proposal

List of committee members, and their affiliation to GeoTools/GeoServer steering/management commitees:

• Andrea Aime (gt/gs): +1
• Alessio Fabiani (gs): +1
• Ben Caradoc Davies (gt/gs): +1
• Chris Holmes (gt/gs):
• Christian Mueller (gt/gs): +1
• Gabriel Roldan (gs):
• Ian Turton (gt):
• Justin Deoliveira (gt/gs): +1
• Jody Garnett (gt/gs): +1
• Mark Leslie (gs):
• Rob Atkinson (gs):
• Simone Giannecchini (gt/gs):

GeoTools:

• Timed Release

Initial discussion on the mailing list: Discussing a switch to a time boxed release model