MapGuide Release Process - Revision history

Wiki-Jasonbirch at 04:08, 16 March 2007

2007-03-16T04:08:57Z

Wiki-Tomfukushima at 17:58, 14 December 2006

2006-12-14T17:58:28Z

Wiki-Jasonbirch: /* Release Schedule */

2006-10-27T01:10:19Z

Release Schedule

Wiki-Jasonbirch: /* Beta Release */

2006-10-27T01:09:07Z

Beta Release

Wiki-Jasonbirch: /* Bug Fix Release */

2006-10-27T01:07:56Z

Bug Fix Release

Wiki-Jasonbirch: /* Bug Fix Release */

2006-10-27T01:06:11Z

Bug Fix Release

Wiki-Pagameba at 20:07, 26 October 2006

2006-10-26T20:07:20Z

Wiki-Pagameba at 19:57, 26 October 2006

2006-10-26T19:57:24Z

New page

==MapGuide Release Process==

This document details the process the MapGuide PSC and development team will follow to create releases of MapGuide Open Source.

The process is intended to be a flexible tool used by the MapGuide PSC to ensure new features are regularly made available to the community through formal releases, while maintaining a reasonable level of control over when and how releases are made.

There are several core concepts to the release process:

* Versioning
* Release Types
* Release Schedule

===Version Numbering===

MapGuide follows a traditional version numbering scheme using three numeric fields separated by periods. The three fields denote the major version number, the minor version number and the bugfix version number respectively.

Version numbers will be changed by single digit increments for each subsequent release of the same type.

Version numbers for bugfixes start at 0 for a new minor release. Version numbers for minor releases start at 0 for a new major release.

===Release Types===

There are several release types, each related to a particular part of the version numbering scheme:

* Major Release
* Minor Release
* Bug Fix Release
* Beta Release
* Release Candidate
* Final Release

====Major Release====

A major release is one that changes the major version number. The PSC can make any release a major release. There is no fixed schedule for a major release. A major release should be considered when there are major architectural changes or a substantial set of new features since the last major release.

====Minor Release====

A minor release is one that changes the minor version number for a given major release. Approximately two minor releases are made in each calendar year, ideally about 6 months apart. A minor release happens automatically and includes any new, stable features as decided by the PSC.

The PSC may advance or delay a minor release as required to accomodate development schedules. However, it is important for the PSC to consider the impact of delaying a minor release on the deployment of existing unreleased features.

====Bug Fix Release====

A bugfix release is one taht changes the bugfix version number for a given minor release. Bugfix releases can be made at any time. Generally, a bugfix release will include several minor bug fixes. However, a bugfix release can be made for a single bug fix if it is deemed necessary for security or functional reasons.

====Beta Release====

A beta release precedes any major or minor release. At least one beta release will be made before a final release of a major or minor version can be made. More than one beta release can be made if warranted by feedback on the mailing list. A beta release should be considered a 'feature complete' version with potential known issues. No new features should be added to a version after the first beta release. The PSC may vote to allow additional features in a release after the beta release process has started, but any new feature must result in another beta release.

====Release Candidate====

A release candidate follows the final beta release and precedes any major or minor release. At least one release candidate will be made before a final release of a major or minor version can be made. More than one release candidate can be made if warranted by feedback on the mailing list. A release candidate should be considered 'feature complete' and free of serious, known issues. Minor known issues may exist in a release candidate, but should be documented in the release notes.

Under no circumstances will new features be admitted to a version following a release candidate.

====Final Release====

A final release is approved by the PSC following a release candidate if no significant problems are uncovered.

===Release Schedule===

The MapGuide PSC is responsible for determining the MapGuide release schedule in the (link) MapGuide Road Map. As noted, a minor release will occur approximately twice in a calendar year.

← Older revision		Revision as of 04:08, 16 March 2007
Line 1:		Line 1:
−	~~==MapGuide Release Process==~~	+	This page has moved here:

−	~~This document details the process the MapGuide PSC and development team will follow to create releases of MapGuide Open Source.~~	+	http://mapguide.osgeo.org/releaseprocess.html
−
−	The process is intended to be a flexible tool used by the MapGuide PSC to ensure new features are regularly made available to the community through formal releases, while maintaining a reasonable level of control over when and how releases are made.
−
−	~~There are several core concepts to the release process:~~
−
−	* Versioning
−	* Release Types
−	* Release Schedule
−	* Release Process
−	* Release Manager
−
−	~~===Version Numbering===~~
−
−	MapGuide follows a traditional version numbering scheme using three numeric fields separated by periods. The three fields denote the major version number, the minor version number and the bugfix version number respectively.
−
−	~~Version numbers will be changed by single digit increments for each subsequent release of the same type.~~
−
−	~~Version numbers for bugfixes start at 0 for a new minor release. Version numbers for minor releases start at 0 for a new major release.~~
−
−	~~===Release Types===~~
−
−	~~There are several release types, each related to a particular part of the version numbering scheme:~~
−
−	* Major Release
−	* Minor Release
−	* Bug Fix Release
−	* Beta Release
−	* Release Candidate
−	* Final Release
−
−	~~====Major Release====~~
−
−	A major release is one that changes the major version number. The PSC can make any release a major release. There is no fixed schedule for a major release. A major release should be considered when there are major architectural changes or a substantial set of new features since the last major release.
−
−	~~====Minor Release====~~
−
−	A minor release is one that changes the minor version number for a given major release. Approximately two minor releases are made in each calendar year, ideally about 6 months apart. A minor release happens automatically and includes any new, stable features as decided by the PSC.
−
−	The PSC may advance or delay a minor release as required to accomodate development schedules. However, it is important for the PSC to consider the impact of delaying a minor release on the deployment of existing unreleased features.
−
−	~~====Bug Fix Release====~~
−
−	A bugfix release is one that changes the bugfix version number for a given minor release. Bugfix releases can be made at any time, and solely for limited-scope bug fixes against a stable release branch. Generally, a bugfix release will include several minor bug fixes. However, a bugfix release can be made for a single bug fix if it is deemed necessary for security or functional reasons.
−
−	~~====Beta Release====~~
−
−	A beta release precedes any major or minor release. At least one beta release will be made before a final release of a major or minor version can be made. More than one beta release can be made if warranted by feedback on the mailing list. A beta release should be considered a 'feature complete' version with potential known issues. No new features should be added to a version after the first beta release. Under exceptional circumstances the PSC may vote to allow additional features in a release after the beta release process has started, but any new feature must result in another beta release.
−
−	~~====Release Candidate====~~
−
−	A release candidate follows the final beta release and precedes any major or minor release. At least one release candidate will be made before a final release of a major or minor version can be made. More than one release candidate can be made if warranted by feedback on the mailing list. A release candidate should be considered 'feature complete' and free of serious, known issues. Minor known issues may exist in a release candidate, but should be documented in the release notes.
−
−	~~Under no circumstances will new features be admitted to a version following a release candidate.~~
−
−	~~====Final Release====~~
−
−	~~A final release is approved by the PSC following a release candidate if no significant problems are uncovered.~~
−
−	~~===Release Schedule===~~
−
−	~~The MapGuide PSC is responsible for determining the MapGuide release schedule in the (link) MapGuide Road Map. As noted, a minor release will occur approximately twice in a calendar year.~~
−
−	A first beta release will be made approximately 2 months prior to the expected final release date. If required, a second beta will be released 2-3 weeks following the first beta. If additional beta releases are required, they are released as necessary and will delay the final release.
−
−	A first release candidate will be made approximate 2 weeks following the final beta release. If required, a second release candidate will be generated 2-3 weeks following the first release candidate. If additional release candidates are required, they are released as necessary and will delay the final release.
−
−	~~The final release can be made 2-3 weeks following the final release candidate.~~
−
−	~~=== Release Process ===~~
−
−	~~The MapGuide PSC will determine the approximate date of the next release during regularly scheduled IRC meetings.~~
−
−	~~Approximately 2 months before a scheduled release, a Release Manager will be appointed and an initial release plan will be formed.~~
−
−	~~After the first release candidate has been cut, work will start to document the new features in the release (since no new features can be added) for the release notes and web site updates.~~
−
−	~~===Release Manager===~~
−
−	~~The release manager is responsible to the PSC for ensuring that the various stages of the release happen on schedule, including~~:
−
−	* preparation of binary builds and source code packages
−	* documentation updates
−	* preparing the release notes
−	* inform developers via the dev mailing list at least two weeks before the release about the release; inform that all submissions need to be done one week before the release date so that adequate time is left for preparation of the posting
−	* work with the FDO PSC to find out which version of FDO to use
−
−	~~Note that the release manager does not necessarily do these things, these roles may be filled by others. The release manager makes sure that they actually happen~~.
−
−	~~The release manager reports to the PSC at regular intervals to provide assurance that the release is proceeding normally~~. ~~The release manager will make recommendations to the PSC as required to adjust the release schedule and to accomodate new features during the beta phase~~.

@@ Line 85: / Line 85: @@
 * documentation updates
 * preparing the release notes
 Note that the release manager does not necessarily do these things, these roles may be filled by others.  The release manager makes sure that they actually happen.
 The release manager reports to the PSC at regular intervals to provide assurance that the release is proceeding normally.  The release manager will make recommendations to the PSC as required to adjust the release schedule and to accomodate new features during the beta phase.

@@ Line 66: / Line 66: @@
 A first beta release will be made approximately 2 months prior to the expected final release date.  If required, a second beta will be released 2-3 weeks following the first beta.  If additional beta releases are required, they are released as necessary and will delay the final release.
-A first release candidate will be made approximate 2 weeks following the final beta release.  If required, a second beta will be released 2-3 weeks following the first release candidate.  If additional release candidates are required, they are released as necessary and will delay the final release.
+A first release candidate will be made approximate 2 weeks following the final beta release.  If required, a second release candidate will be generated 2-3 weeks following the first release candidate.  If additional release candidates are required, they are released as necessary and will delay the final release.
 The final release can be made 2-3 weeks following the final release candidate.

@@ Line 44: / Line 44: @@
 ====Bug Fix Release====
-A bugfix release is one that changes the bugfix version number for a given minor release.  Bugfix releases can be made at any time.  Generally, a bugfix release will include several minor bug fixes.  However, a bugfix release can be made for a single bug fix if it is deemed necessary for security or functional reasons.
+A bugfix release is one that changes the bugfix version number for a given minor release.  Bugfix releases can be made at any time, and solely for limited-scope bug fixes against a stable release branch.  Generally, a bugfix release will include several minor bug fixes.  However, a bugfix release can be made for a single bug fix if it is deemed necessary for security or functional reasons.
 ====Beta Release====

@@ Line 48: / Line 48: @@
 ====Beta Release====
-A beta release precedes any major or minor release.  At least one beta release will be made before a final release of a major or minor version can be made.  More than one beta release can be made if warranted by feedback on the mailing list.  A beta release should be considered a 'feature complete' version with potential known issues.  No new features should be added to a version after the first beta release.  The PSC may vote to allow additional features in a release after the beta release process has started, but any new feature must result in another beta release.
+A beta release precedes any major or minor release.  At least one beta release will be made before a final release of a major or minor version can be made.  More than one beta release can be made if warranted by feedback on the mailing list.  A beta release should be considered a 'feature complete' version with potential known issues.  No new features should be added to a version after the first beta release.  Under exceptional circumstances the PSC may vote to allow additional features in a release after the beta release process has started, but any new feature must result in another beta release.
 ====Release Candidate====

@@ Line 10: / Line 10: @@
 * Release Types
 * Release Schedule
 ===Version Numbering===
@@ Line 61: / Line 63: @@
 The MapGuide PSC is responsible for determining the MapGuide release schedule in the (link) MapGuide Road Map.  As noted, a minor release will occur approximately twice in a calendar year.