This document describes the process that the GeoServer community uses to handle contributions and additions to the project. This process is used to manage new features and additions to the project, as well as for short and long term project planning.
The GeoServer community process adheres to the following guidelines to ensure that it retains open development practices:
- Transparency Project decisions are made in an open and transparent way. Key decisions are presented GeoServer Improvement Proposals (GSIP), discussed in public. When a decision is made it is clear as to why it was made.
- Open Proposals are presented on the GeoServer wiki - and anyone can write a proposal (no commit access required).
- Balance Every member of the community is welcome to participate. Project decisions are discussed in public by the community as a whole. Decisions are made by a project steering committee and not subject to the whims of any single developer or organizations.
- Responsibility The Project Steering Committee is responsible the strategic direction of the GeoServer project. Central to this responsibility is evaluating proposals and providing a clear decision through a public voting process.
During the development cycle community members propose new features and improvements to be included in the release. The following are the prerequisites for proposing a new feature:
- The feature has a sponsor. This means either a developer willing to carry out the work or a customer who is paying for it.
- The feature has has gone through the GSIP process if necessary. Whether a feature requires a GSIP is decided by the community when the feature is proposed.
The determining factor for what release a feature should be included in is based on the estimate of the time to implement the feature, and the current Release cycle. The release cycle includes a “feature freeze” where new features are delayed while stabilize master and cut a new release candidate.
New features may be back-ported to the stable series (if technically feasible) after being tried out on master for a month.
GeoServer follows a time-boxed release model, this allows new features to be developed for the project with a set expectation of when a feature will be available for use.
The community maintains three active branches:
- master: available for development of new functionality, documentation improvements and bug fixes
- stable: bug fixes and back-port of new functionality that do not affect the GeoServer API or significantly affect stability.
- maintenance: bug fixes
For each GeoServer release we spend six month “prerelease” in a development cycle on the master branch, followed by six months as the stable release, followed by six months as the maintenance release.
- Month -6: master open for development
- Month -1: month: beta release is made (starting a feature freeze)
- Month 1: (start of month): release candidate is made on new branch (ending the feature freeze)
- Month 1: initial stable release (aim for two weeks after the release candidate)
- Month 3: stable release
- Month 5: stable release
- Month 7: maintenance release
- Month 9: maintenance release
- Month 11: maintenance release
We alternate between releasing the stable and maintenance branches. A release goes out each month forming a yearly release cycle.
Here is what that looks like:
- Month 1: Release N.0 stable
- Month 2: (previous branch N-1 issues a maintenance release)
- Month 3: Release N.1 stable
- Month 4: (previous branch N-1 issues a maintenance release)
- Month 5: Release N.2 stable
- Month 6: (next branch N+1 issues a stable release)
- Month 7: Release N.3 maintenance
- Month 8: (next branch N+1 issues a stable release)
- Month 9: Release N.4 maintenance
- Month 10: (next branch N+1 issues a stable release)
- Month 11: Release N.5 maintenance
For more information, or to volunteer, please check the release schedule in the wiki.
Additional releases may be requested by downstream projects at any point, or may be produced by a volunteer to quickly disseminate a security fix.
Additional stable (or maintenance releases) will use the next available version number. This does not disrupt the release schedule above. We expect volunteers to use common sense and collaborate rather than issue two releases during the same week.
Patch releases are formed by branching from a previous release tag, applying a fix, and issuing a release. Patch releases are versioned appropriately.
As an example GeoServer 22.214.171.124 is a patch release started by branching the GeoServer 2.5.5.