Author: sebor Date: Wed Oct 31 21:00:04 2007 New Revision: 590883 URL: http://svn.apache.org/viewvc?rev=590883&view=rev Log: 2007-10-31 Martin Sebor * releases.html: First draft of the release policy. Added: incubator/stdcxx/site/releases.html (with props) Added: incubator/stdcxx/site/releases.html URL: http://svn.apache.org/viewvc/incubator/stdcxx/site/releases.html?rev=590883&view=auto ============================================================================== --- incubator/stdcxx/site/releases.html (added) +++ incubator/stdcxx/site/releases.html Wed Oct 31 21:00:04 2007 @@ -0,0 +1,170 @@ + + + Apache C++ Standard Library Release Process + + +

Apache C++ Standard Library Release Process

+

Draft

+

Last Updated: October 31, 2007

+

Purpose Of This Document

+

+ +The purpose of this document is to describe the Apache C++ Standard Library release process and versioning policy. + +

+ +

Roles During a Release

+

+ +The project committers collectively decide when to start the release process. They decide on the Release Criteria and nominate a Release Manager from amongst themselves. The Release Manager is responsible for coordinating the stages of the release cycle, facilitating communication among developers throughout the process, and for guiding the release process to completion. With the help of other committers, the Release Manager decides on the set of features and bug fixes to be implemented in a release and on a realistic schedule for it. Throughout the release process the Release Manager adheres to the Release Criteria initially agreed upon by all committers. Changes to the Release Criteria require the consent of all committers. + +

+ +

Stages of the Release Process

+ +
    +
  1. + Planning +
      +
    1. Decide on Roadmap
    2. +
    3. + Decide on + Primary Target Platforms +
    4. +
    5. + Decide on + Secondary Target Platforms +
    6. +
    +
  2. +
  3. + Development +
      +
    1. Issue Prioritization and Scheduling
    2. +
    3. Issue Resolution
    4. +
    +
  4. +
  5. + Feature Freeze +
      +
    1. Create a release branch
    2. +
    3. Create release candidates
    4. +
    +
  6. +
  7. + Code Freeze +
      +
    1. Create a final release candidate
    2. +
    3. Vote to approve release candidate
    4. +
    5. Fix issues uncovered during the vote and restart process
    6. +
    +
  8. +
  9. Cut a Release
  10. +
+ +

+ +

Primary Target Platforms

+

+ +A known set of platforms deemed to be the most important for the release. Typically, this is a set of combinations of compilers, operating systems, and hardware architectures, and their major versions. The set is decided based on the popularity or demand for the project on those platforms. The goal is to provide the best possible user experience on these platforms, with as few compilation or link time warnings as possible (ideally none), and with all tests passing at 100%. As an example, the set of Primary Platforms can consist of gcc 4 on Red Hat Linux 5/x86_64 and Sun Studio 12 on Solaris 10/SPARC. + +

+ +

Secondary Target Platforms

+

+ +A known set of platforms to be fully supported in the release. The goal is to make the project usable on these platforms without necessarily providing an ideal user experience. No compilation or linker failures should exist on Secondary Platforms but some warnings can be expected, and not all tests need pass at 100%. All failures should be analyzed and documented in the form of issues in the bug tracking database. + +

+ +

Best Effort Platforms

+

+ +A known set of platforms the project builds in some but not necessarily all configurations and is mostly usable but some features may be compromised. Possibly extensive failures in the test suite are to be expected. Not all failures need be analyzed or documented. + +

+ +

Unsupported Platforms

+

+ +Platforms where the project is known not to build or be usable. These may be initial target platforms to which fully porting the project turned oput to be infeasible (e.g., due to availability). + +

+ +

Issue Prioritization and Scheduling

+

+ +Blockers should be scheduled for the next earliest micro (patch) release provided the issue can be resolved in a forward compatible way. When no micro release is scheduled at the time a Blocker is issue filed, scheduling one should be considered. Unless the binary compatibility policy prevents resolving a Blocker, a release shouldn't go out that has Blockers filed against it. The Release Manager can negotiate a lower priority of an issue with its reporter in order to defer resolving it until later. + +

+

+ +Critical issues and regressions that aren't blockers should be scheduled for the next earliest release whose version number allows it (as per the versioning and compatibilty policy). It is up to the discretion of the Release Manager to defer issues if circumstances necessitate it. + +

+ +

Development Branches

+

+ +Development of new features and extensive/invasive bug fixes or improvements takes place either on trunk, or on platform or special project branches, or on future major release branches. These are collectively known as development branches. + +

+ +

Maintenance Branches

+

+ +Maintenance takes place on maintenance branches. A minor release branch (e.g., the 4.2.x branch created for the 4.2.0 release) becomes a maintenance branch after the minor version is released. Since maintenance releases must be both backward and forward compatible, only bug fixes or compatible improvements can take place on maintenance branches. New features are typically not implemented on maintenance branches. + +

+ +

Feature Freeze

+

+ +When the Release Manager considers the scheduled set of new features and major bug fixes to be fully implemented and the development branch sufficiently stable he or she creates a release branch if one doesn't yet exist, and announces a Feature Freeze. It's a good idea to give a heads up on an upcoming Feature Freeze date at least two weeks in advance. After a Feature Freeze, all committers must follow the Review-Then-Commit policy on the release branch, with the Release Manager having the authority to approve or reject any or all changes. Typically, only issues discovered during the testing of the release branch should be fixed there. Other non-intrusive bug fixes might be also allowed to merged in from trunk or other branches at the discretion of the Release Manager. The Release Manager effectively owns the release branch. The Release Manager should tag the release branch at this point (e.g., as the first release candidate), and continue to do as the branch stabilizes. Changes made directly on the release branch should be merged to trunk or other branches when appropriate. Development on trunk and other branches can continue unaffected. + +

+ +

Code Freeze

+

+ +After the Release Manager is satisfied that the release branch meets the Release Criteria, he or she announces a Code Freeze. It is a good idea to give a heads up on an upcoming Code Freeze date at least two weeks in advance. During a Code Freeze, only documentation and other similar changes are permitted on the release branch under the Review-Then-Commit policy. No code changes should be made, except to resolve newly uncovered release-blocking issues. When the Release Manager considers the release branch ready he or she creates the final release candidate and starts a vote to approve the release. It is the responsibility of the Release Manager to make sure that all changes made on the release branch are merged to trunk or other branches as appropriate. + +

+ +

Release Criteria

+

+ +The desirable set of Release Criteria should include the following requirements: +

+ + + Propchange: incubator/stdcxx/site/releases.html ------------------------------------------------------------------------------ svn:eol-style = native Propchange: incubator/stdcxx/site/releases.html ------------------------------------------------------------------------------ svn:keywords = Id