stdcxx-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From se...@apache.org
Subject svn commit: r590883 - /incubator/stdcxx/site/releases.html
Date Thu, 01 Nov 2007 04:00:20 GMT
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  <sebor@roguewave.com>

	* 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



Mime
View raw message