Summary of proposal

Brent Owens

Guidelines and documentation specific to releases

Completed and is done.

http://jakarta.apache.org/commons/releases/versioning.html

Jira Roadmap:

• geoserver roadmap

Effected Policies and Procedures from the Developers Guide:

• [GEOSDOC:7 Releasing]
• [GEOSDOC:Deploying]
• [GEOSDOC:Pre-Release Testing Walkthrough]

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.

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.

All public releases must pass CITE tests.

There are three sections to the release page: Stable Latest Experimental

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.

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.

major.minor.pointsubpoint* 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.

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.

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.

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

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.401) and does not have to wait for the PSC to organize it. These releases +cannot+ go under thestable* 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.

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.

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: 1.4.0-RC1_beta 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.