|
|
Home | Docs | Issue Tracker | FAQ | Download |
|
|
| Date: | 2007/07/13 |
|---|---|
| Author: | Daniel Morissette |
| Contact: | dmorissette at mapgears.com |
| Last Edited: | 2007/07/19 |
| Status: | Adopted (2007/07/19) |
| Id: | $Id$ |
This RFC documents the MapServer Release Manager role and the phases of MapServer’s Release Process.
For every release of MapServer, the PSC elects a release manager (this is usually done with a motion and vote on the mapserver-dev list).
The overall role of the release manager is to coordinate the efforts of the developers, testers, documentation and other contributors to lead to a release of the best possible quality within the scheduled timeframe.
The PSC delegates to the release manager the responsibility and authority to make certain final decisions for a release, including:
When in doubt or for tough decisions (e.g. pushing the release date by several weeks) the release manager is free to ask the PSC to vote in support of some decisions, but this is not a requirement for the areas of responsibility above.
The release manager’s role also includes the following tasks:
Any of the above tasks can be delegated but they still remain the ultimate responsibility of the release manager.
(Credit: Inspired by the Plone release process at http://plone.org/documentation/manual/plone-developer-reference/overview/release-process)
MapServer uses a time-based release cycle, trying to aim for one release every 6 months.
The normal development process of a MapServer release consists of various phases.
Development phase
The development phase usually lasts around 4 months. New features are proposed via RFCs voted by the MapServer PSC.
RFC freeze date
For each release there is a certain date by which all new feature proposals (RFCs) must have been submitted for review. After this date no features will be accepted anymore for this particular release.
Feature freeze date / Beta releases
By this date all features must have been completed and all code has to be integrated. Only non-invasive changes, user interface work and bug fixes are done now. We usually plan for 3-4 betas and a couple of release candidates over a 6 weeks period before the final release.
Release Candidate
Ideally, the last beta that was bug free. No changes to the code. Should not require any migration steps apart from the ones required in the betas. If any problems are found and fixed, a new release candidate is issued.
Final release / Expected release date
Normally the last release candidate that was issued without any show-stopper bugs.
Bug fix releases
No software is perfect. Once a sufficient large or critical number of bugs have been found for a certain release, the release manager releases a new bug fix release a.k.a. third-dot release (for example 4.10.2).
MapServer’s version numbering scheme is very similar to Linux’s. For example, a MapServer version number of 4.2.5 can be decoded as such:
4: Major version number.
We release a major version every two to three years. The major version number usually changes when significant new features are added or when major architectural changes or backwards incompatibilities are introduced.
2: Minor version number.
Increments in minor version number almost always relate to additions in functionality and correspond to the 6 months release process described in this RFC.
MapServer uses the same even/odd minor version number scheme as Linux. Even minor version numbers (0..2..4..6) relate to release versions, and odd minor versions (1..3..5..7) correspond to developmental versions. For instance development version 4.1 was released as version 4.2.0, there was never any formal release of 4.1.
5: Revision number.
Revisions are bug fixes only. No new functionality is provided in revisions.
Vote completed on 2007/07/19.
+1 from DanielM, SteveL, SteveW, FrankW, TamasS, AssefaY, JeffM, PericlesN, UmbertoN and HowardB.