This page last changed on Jan 09, 2007 by jive.

GSIP 5 - GeoServer Release Process


Summary of proposal

Proposed By


Proposal Type

Guidelines and documentation specific to releases

Assigned to release


Completed and is done.


Read Jakarta's version page for more information and ideas:

Jira Roadmap:

Effected Policies and Procedures from the Developers Guide:

Email discussion:

Other wiki discussions:


At the current state anyone can release whenever they want, and there is no coordination between branches, especially with respect to version numbers.
Now that GeoServer has a PSC it should be up to the members to determine when to release and what to call it, instead of individual developers. An agreed upon naming convention is also needed.


1) Release scheduling

Releases should be scheduled for regular intervals: once per month for the main development branches of GeoServer (trunk, 1.3.x, WCS).
For special releases off of the schedule, the PSC must determine for each release:

  • The release date. This should be around the same time every month, plus or minus a couple of days.
  • The person(s) to make the release. The person(s) must agree to do the release or else the PSC must release themselves. They must be notified well in advance.
  • Content of the release.
  • Release version number.
  • Release off of released versions of GeoTools. If GeoTools can release once a month as well, GeoServer should use that release pending that it passes CITE tests. If not, a previous GeoTools version should be used. Sometimes during release cycles of GeoServer, minor changes will need to be made to GeoTools. In this case it does not make sense to make many small releases of GeoTools. In this case a snapshot release will be sifficient.

Intermediate releases can be made but must follow naming conventions.

2) CITE Tests

All public releases must pass CITE tests.

3) Release Page

There are three sections to the release page:

Stable: Major, minor, or point releases that have passed through beta stages and been through a full release and tested by the public.
Latest: Major, minor, or point releases that are on a main development branch that has been released before. Does not have to be publically tested. They can be beta versions.
Experimental: Major, minor, or point releases that are not on the main development branch. Milestone releases fit here.

4) Branches

Experimental branches must arrange with the PSC to announce the release and determine an appropriate version number and name. Experimental branches must be released under the Experimental section of the GeoServer download page. Rules for each experimental branch can be discussed by the PSC on a case-by-case basis.

5) Naming conventions

example: 1.3.4_02

Release names can also contain extra information such as RC (Release Candidate), M (Milestone), and should correspond to Maven standards for release names. You must run CITE tests to release.

5.1) Major Release

Major releases do not have to have a backwards compatible API. They are complete feature changes that require dependant projects to migrate towards. You must run CITE tests to release.

5.2) Minor Release

Minor releases must have a backwards compatible API. They can contain major or minor changes and new features to the modules that do not require dependant projects to migrate. You must run CITE tests to release.

5.3) Point Release

Point releases are just bug fixes and very minor changes. The API must be backwards compatible. You must run CITE tests to release.

5.4) Immediate Releases (sub-point releases)

It sometimes happens where a group of developers may need a release out immediately (for conferences, demos, minor fix, etc). These can be named with the sub-point-release version number ( _##, example: 1.3.4_01) and does not have to wait for the PSC to organize it. These releases cannot go under the stable download page and must pass CITE tests to go under the latest download page.
Changes that can take place in the sub_point release are: minor UI fixes, non-programming fixes, minor/trivial bug fixes.

6) Major and Minor releases

Major releases and minor releases should go through release candidates before the official release. During this phase they will be labeled beta on the file names. Once they have gone through a release candidate successfully then they can be released under the stable section of the download page. Until then they are released under the Latest section of the web page.

7) Beta releases

If a release is approaching a minor or major release but is still being tested, beta must be attached to the end of the file name:
This should be on all release candidates and milestone releases of the major or minor release version.
Note that this should just be on the file names and in the UI, not the version numbers so we don't mess with maven.


Discuss in the meetings and come up with an agreed upon plan for the wiki.

We have a bit of a problem with the naming conventions diverting from standard maven use - since the relesaes are now being used by those using geoserver as an geo service SDK we should try and fall in line. So 1.5.0, 1.5.0-SNAPSHOT 1.5.0-M1 etc...

Posted by jive at Sep 26, 2006 00:59

I'd like to kill the use of 'milestone' in our naming convention. It's really a java/eclipse thing that few people outside know. People know the term 'beta', and know that if they're using it they're expecting it to not work perfectly. People don't know the same for mileston.

Posted by cholmes at Sep 26, 2006 13:03

I also don't think that we should have RC_beta. We didn't do things right with 1.3.x, as we had tons of RC's that really should have been betas.

What I propose is:
beta for anything that's still actively developed.
RC for feature freeze - bug fixes only.

If you want to say this is really not ready you can call it 'alpha'.

The final RC should be the same as the first .0, when we are sure there are no little annoying bugs, when it's been sufficiently tested by users.

Posted by cholmes at Sep 26, 2006 13:07

 There is a fair bit of overhead for an organisation to upgrade a data service that someone else depends upon. (and what else if a WFS after all?).

 So, at the very least we should make a much more prominent "whats changed" section, and an executive summary.

Look at it from the perspective of someone who has

a) a production service, with a few known bugs that might be fixed

b) a development activity wanting to know whether the new build fixes issues that are causing pain

Posted by rob_cto_sco at Oct 26, 2006 18:24
Document generated by Confluence on May 14, 2014 23:00