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 <[EMAIL PROTECTED]>
* 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 @@
+<html>
+ <head>
+ <title>Apache C++ Standard Library Release Process</title>
+ </head>
+ <body>
+ <h1><center>Apache C++ Standard Library Release Process</center></h1>
+ <h3><center>Draft</center></h3>
+ <h4><center><i>Last Updated: October 31, 2007</i></center></h4>
+ <h2>Purpose Of This Document</h2>
+ <p>
+
+The purpose of this document is to describe the Apache C++ Standard Library
release process and versioning policy.
+
+ </p>
+ <a name="roles"></a>
+ <h2>Roles During a Release</h2>
+ <p>
+
+The project committers collectively decide when to start the release process.
They decide on the <i><a href="#release_criteria">Release Criteria</a></i> and
nominate a <i>Release Manager</i> 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.
+
+ </p>
+ <a name="stages_of_release"></a>
+ <h2>Stages of the Release Process</h2>
+
+ <ol>
+ <li>
+ Planning
+ <ol>
+ <li>Decide on Roadmap</li>
+ <li>
+ Decide on <a href="#primary_platforms">
+ Primary Target Platforms</a>
+ </li>
+ <li>
+ Decide on <a href="#secondary_platforms">
+ Secondary Target Platforms</a>
+ </li>
+ </ol>
+ </li>
+ <li>
+ Development
+ <ol>
+ <li>Issue Prioritization and Scheduling</li>
+ <li>Issue Resolution</li>
+ </ol>
+ </li>
+ <li>
+ <a href="#feature_freeze">Feature Freeze</a>
+ <ol>
+ <li>Create a release branch</li>
+ <li>Create release candidates</li>
+ </ol>
+ </li>
+ <li>
+ <a href="#code_freeze">Code Freeze</a>
+ <ol>
+ <li>Create a final release candidate</li>
+ <li>Vote to approve release candidate</li>
+ <li>Fix issues uncovered during the vote and restart process</li>
+ </ol>
+ <li>
+ <li>Cut a Release</li>
+ </ol>
+
+ </p>
+ <a name="primary_platforms"></a>
+ <h2>Primary Target Platforms</h2>
+ <p>
+
+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.
+
+ </p>
+ <a name="secondary_platforms"></a>
+ <h2>Secondary Target Platforms</h2>
+ <p>
+
+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.
+
+ </p>
+ <a name="best_effort_platforms"></a>
+ <h2>Best Effort Platforms</h2>
+ <p>
+
+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.
+
+ </p>
+ <a name="unsupported_platforms"></a>
+ <h2>Unsupported Platforms</h2>
+ <p>
+
+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).
+
+ </p>
+ <a name="issue_scheduling"></a>
+ <h2>Issue Prioritization and Scheduling</h2>
+ <p>
+
+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.
+
+ </p>
+ <p>
+
+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.
+
+ </p>
+ <a name="development_branches"></a>
+ <h2>Development Branches</h2>
+ <p>
+
+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.
+
+ </p>
+ <a name="branches_branches"></a>
+ <h2>Maintenance Branches</h2>
+ <p>
+
+Maintenance takes place on maintenance branches. A minor release branch (e.g.,
the <a
href="http://svn.apache.org/repos/asf/incubator/stdcxx/branches/4.2.x/";>4.2.x</a>
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.
+
+ </p>
+ <a name="feature_freeze"></a>
+ <h2>Feature Freeze</h2>
+ <p>
+
+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 <a
href="http://www.apache.org/foundation/glossary.html#ReviewThenCommit";>Review-Then-Commit</a>
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.
+
+ </p>
+ <a name="code_freeze"></a>
+ <h2>Code Freeze</h2>
+ <p>
+
+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.
+
+ </p>
+ <a name="release_criteria"></a>
+ <h2>Release Criteria</h2>
+ <p>
+
+The desirable set of Release Criteria should include the following
requirements:
+ </p>
+ <ul>
+ <li>
+
+All issues sheduled for the release have been resolved.
+
+ </li>
+ <li>
+
+No compilation or linker errors in the test suite (including example programs)
on Primary and Secondary target platforms.
+
+ </li>
+ <li>
+
+No test failures, including failed assertions, on Primary Target Platforms.
+
+ </li>
+ <li>
+
+ No build failures on Best Effort Platforms.
+
+ </li>
+ <li>
+
+ </li>
+ <li>
+
+ Any outstanding test failures on Secondary Platforms are recorded in the form
of issues in the bug tracking database.
+ </li>
+ </ul>
+ </body>
+</html>
Propchange: incubator/stdcxx/site/releases.html
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: incubator/stdcxx/site/releases.html
------------------------------------------------------------------------------
svn:keywords = Id
