Author: sebor
Date: Mon Nov 12 19:56:39 2007
New Revision: 594420
URL: http://svn.apache.org/viewvc?rev=594420&view=rev
Log:
2007-11-12 Martin Sebor <[EMAIL PROTECTED]>
* releases.html: Incorporated feedback from the first review.
(Index, Goals, Definitions, References, Compatibility, Version
Policy): Added new sections.
(Roles): Removed. Replaced with the new Release Manager entry
of the Definitions section.
(Stages): Reworked, expanded.
Modified:
incubator/stdcxx/site/releases.html
Modified: incubator/stdcxx/site/releases.html
URL:
http://svn.apache.org/viewvc/incubator/stdcxx/site/releases.html?rev=594420&r1=594419&r2=594420&view=diff
==============================================================================
--- incubator/stdcxx/site/releases.html (original)
+++ incubator/stdcxx/site/releases.html Mon Nov 12 19:56:39 2007
@@ -1,41 +1,91 @@
<html>
<head>
- <title>Apache C++ Standard Library Release Process</title>
+ <title>
+ Apache C++ Standard Library Release Process and Version Policy
+ </title>
</head>
<body>
- <h1><center>Apache C++ Standard Library Release Process</center></h1>
- <h3><center>Draft</center></h3>
- <h4><center><i>Last Updated: $Id$</i></center></h4>
+ <h1>
+ <center>
+ Apache C++ Standard Library Release Process and Version Policy
+ </center>
+ </h1>
+ <h3><center>Second Draft</center></h3>
+ <h4>
+ <center>
+ <i>
+ Last Updated: $Id$
+ </i>
+ </center>
+ </h4>
<hr>
+
+ <h2>Index</h2>
+ <ol>
+ <li><a href="#purpose">Purpose Of This Document</a></i>
+ <li><a href="#goals">Goals</a></i>
+ <li><a href="#stages">Stages of the Release Process</a></i>
+ <li><a href="#definitions">Definitions</a></i>
+ <li><a href="#version_policy">Version Policy</a></i>
+ <li><a href="#references">References</a></i>
+ </ol>
+
<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.
+The purpose of this document is to describe the Apache C++ Standard
+Library development and release processes, and version policy. A
+Release Process is a sequence of steps that starts with deciding what
+changes should be made to the project and culminates in the distribution
+of the updated project code base to the public.
</p>
- <a name="roles"></a>
- <h2>Roles During a Release</h2>
- <p>
+ <a name="goals"></a>
+ <h2>Goals</h2>
+ <ul>
+ <li>
-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.
+The goal of the development process is to maintain a stable code base
+at all times to make it possible to start the release process at any
+point in time. It should be possible to check out the head of trunk or
+the head of any maintenance branch at any revision and build and use
+it on any platform.
- </p>
- <a name="stages_of_release"></a>
+ </li>
+ <li>
+
+The goal of the release process is to produce periodic stable releases
+that meet the <a href="#release_criteria">Release Criteria</a>. The
+frequency of releases isn't precisely defined but a 3 to 6 month cycle
+appears desirable for maintenance releases. To maintain a high degree
+of stability and compatibility, minor releases should not occur more
+frequently than once every 12 to 18 months. Major releases should
+occur rarely, ideally not more often than once every 5 to 10 years.
+
+ </li>
+ <li>
+
+Large scale long term projects whose stability may fluctuate over time
+and where maintaining a stable code base at all times is impractical
+take place on special project or platform branches. Development on
+such branches isn't subject to the same development and release
+process.
+
+ </li>
+ </ul>
+
+ <a name="stages"></a>
<h2>Stages of the Release Process</h2>
<ol>
<li>
- Planning
+ <a href="#release_cycle">Start the Release Cycle</a>
<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>
+ <a href="#establishing_release_criteria">
+ Establish Release Criteria</a>
</li>
+ <li>Appoint Release Manager</li>
</ol>
</li>
<li>
@@ -49,122 +99,524 @@
<a href="#feature_freeze">Feature Freeze</a>
<ol>
<li>Create a release branch</li>
- <li>Create release candidates</li>
+ <li>Create pre-release candidates</li>
</ol>
</li>
<li>
<a href="#code_freeze">Code Freeze</a>
<ol>
- <li>Create a final release candidate</li>
+ <li>Create the 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>
+ </li>
+ <li>Cut the Release</li>
+ <ol>
+ <li>Tag the Release Branch</li>
+ <li>Create Distribution</li>
+ <li>Upload Distribution to the <a
href="http://people.apache.org/dist/incubator/stdcxx/releases/";>releases</a>
directory</li>
+ <li>Update <a href="download.html">Download</a> page</li>
+ </ol>
+ <li>Announce the Release</li>
</ol>
</p>
- <a name="primary_platforms"></a>
- <h2>Primary Target Platforms</h2>
+ <a name="release_cycle"></a>
+ <h2>Start the Release Cycle</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.
+A new release cycle begins automatically after a previous release
+cycle has ended. There may be more than one release cycle in
+progress. For example, there may be a release cycle in progress with
+the goal of releasing a maintenance upgrade and another to put out a
+major revision.
</p>
- <a name="secondary_platforms"></a>
- <h2>Secondary Target Platforms</h2>
+
+ <a name="establish_release_criteria"></a>
+ <h2>Establish Release Criteria</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.
+At the beginning of a release cycle project <a
+href="index.html#committers">committer</a>s collectively establish the
+set of Release Criteria for the release, nominate a <a
+href="#release_manager">Release Manager</a>, and decide on the set of
+target platforms for the release. These steps can take place in any
+order. The Release Criteria must be approved by a vote on the <a
+href="mailto:stdcxx-dev@incubator.apache.org";>stdcxx-dev</a>
+list. The vote must last sufficiently long to give the majority of
+committers the opportunity to participate, or at least 10 days. The
+set of release criteria need not change from one release to the next.
</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.
+It should be noted that anyone, including non-committers, can
+participate in establishing the release criteria or in deciding the
+target platforms. For example, users who are interested in support for
+a particular platform are welcome to suggest it during this stage, or
+file an issue in the bug tracking database requesting such support.
</p>
- <a name="unsupported_platforms"></a>
- <h2>Unsupported Platforms</h2>
+ <a name="release_criteria"></a>
+ <h2>Release Criteria</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).
+The exact set of release criteria is determined at the beginning of
+each release cycle and may change. The desirable set of Release
+Criteria should include the following requirements:
</p>
+ <ul>
+ <li>
+
+All issues scheduled for the release have been resolved.
+
+ </li>
+ <li>
+
+No compilation or linker errors in the test suite (including example
+programs) on <a href="#primary_platforms">Primary</a> and <a
+href="#secondary_platforms">Secondary</a> target platforms.
+
+ </li>
+ <li>
+
+No test failures, including failed assertions, on Primary Target Platforms.
+
+ </li>
+ <li>
+
+No library build failures on <a href="#best_effort_platforms">Best
+Effort Platforms</a>.
+
+ </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>
+
<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.
+Issues filed against the project with the <a class="external"
+href="http://www.atlassian.com/software/jira/docs/latest/issues.html#PriorityLevels";>Priority</a>
+of a Blocker should be scheduled for the next earliest maintenance (or
+micro) release provided the issues can be resolved in a forward
+compatible way. When no maintenance 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 version and compatibility policy). It is up to the
+discretion of the Release Manager to defer issues if circumstances
+necessitate it.
+
+ </p>
+ <p>
+
+All issues scheduled for a release must be either closed, resolved, or
+deferred before the release can go out.
+
+ </p>
+ <a name="version_policy">
+ <h2>Version and Compatibility Policy</h2>
+ <p>
+
+The Version and Compatibility Policy specifies a mechanism, the version
identifier, and a set of rules for expressing the source and compatibility of
releases of the Apache C++ Standard Library.
+
+ </p>
+ <p>
+
+The version identifier is defined as the string
+<tt><major>.<minor>.<micro></tt> or, optionally,
+<tt><major>.<minor>.<micro>.<patch></tt> with
+the meaning below. The version of the library can be determined during
+preprocessing after the first <code>#include</code> of any library
+header by testing the <code>_RWSTD_VER</code> macro which encodes the
+version number in the form of a hexadecimal constant in the form
+<code>0xMMmmuupp</code>, where the letters <code>MM</code> correspond
+to the major number, <code>mm</code> to minor, <code>uu</code> to
+micro, and <code>pp</code> to patch.
</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.
+The <i>major</i> number (the <code>MM</code> component of the
+<code>_RWSTD_VER</code> macro) starts at 1 and is incremented by one
+for each new release that is source or binary incompatible with the
+previous release. Incrementing the major number resets both the minor
+and micro numbers to 0.
+
+ </p>
+ <p>
+
+The <i>minor</i> number (the <code>mm</code> component of the
+<code>_RWSTD_VER</code> macro) starts at 0 and is incremented by one
+for each new release that is backward but not forward compatible with
+the previous release. Incrementing the minor number resets the micro
+number to 0.
+
+ </p>
+ <p>
+
+The <i>micro</i> number (the <code>uu</code> component of the
+ <code>_RWSTD_VER</code> macro) starts at 0 and is incremented by one
+ for each release that contains source code changes that are both
+ backward and forward compatible with the previous release.
+
+ </p>
+ <p>
+
+The optional <i>patch</i> number (the <code>pp</code> component of the
+<code>_RWSTD_VER</code> macro) is unused. It is provided for third
+party distributors of the library such as compiler vendors to make it
+possible for them to make compatible changes in their distribution of
+the library without being concerned with collisions of other
+distributions. Distributors who want to make incompatible changes are
+encouraged to change the name of the library binary and define their
+own version macro.
+
+ </p>
+ <a name="definitions"></a>
+ <h2>Definitions</h2>
+ <p>
+ </p>
+
+ <a name="primary_platforms"></a>
+ <h3>Release Manager</h3>
+ <p>
+
+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 or to the set of Primary
+or Secondary platforms require the consensus of all
+committers. Changes to Best Effort Platforms are up the Release
+Manager's discretion. When the release is done the Release Manager
+makes announcements about the release on news groups and mailing list
+where this information might be of interest.
+
+ </p>
+ <a name="primary_platforms"></a>
+ <h3>Primary Target Platforms</h3>
+ <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, and the available configurations of the library (such as
+optimized, thread-safe, etc.) 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% in all configurations of the
+library.
+
+ </p>
+ <p>
+
+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>
+ <h3>Secondary Target Platforms</h3>
+ <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% in some
+configurations of the library. All failures should be analyzed and
+documented in the form of issues in the bug tracking database.
+
+ </p>
+ <a name="best_effort_platforms"></a>
+ <h3>Best Effort Platforms</h3>
+ <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>
+ <p>
+
+For example, a targeted compiler that generates correct code without
+optimization but has such serious problems optimizing the library code
+as to render the library unusable with optimization is enabled, ...
+
+ </p>
+ <a name="unsupported_platforms"></a>
+ <h3>Unsupported Platforms</h3>
+ <p>
+
+Platforms (including individual configurations on otherwise supported
+target 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 out to be infeasible (e.g., due to availability).
</p>
<a name="development_branches"></a>
- <h2>Development Branches</h2>
+ <h3>Development Branches</h3>
<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.
+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>
+ <h3>Maintenance Branches</h3>
<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.
+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>
+ <h3>Feature Freeze</h3>
<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.
+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 on the <a
+href="mailto:stdcxx-dev@incubator.apache.org";>stdcxx-dev</a>
+list. 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>
+ <h3>Code Freeze</h3>
<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.
+After the Release Manager is satisfied that the release branch meets
+the Release Criteria, he or she announces a Code Freeze on the <a
+href="mailto:stdcxx-dev@incubator.apache.org";>stdcxx-dev</a>
+list. 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>
+ <h3>Compatibility</h3>
+ <ul>
+ <li>
+ <a href="#source_compatibility">Source Compatibility</a>
+ </li>
+ <li>
+ <a href="#binary_compatibility">Binary Compatibility</a>
+ </li>
+ <li>
+ <a href="#backward_compatibility">Backward Compatibility</a>
+ </li>
+ <li>
+ <a href="#forward_compatibility">Forward Compatibility</a>
+ </li>
+ </ul>
+ <a name="source_compatibility"></a>
+ <h4>Source Compatibility</h4>
<p>
-The desirable set of Release Criteria should include the following
requirements:
+<i>Source Compatibility</i>, important at the source code level,
+determines whether two software components in their source form are
+similar enough so that any well-formed program that uses one of the
+components remains well-formed when the component is replaced with the
+other. Source compatible changes are those that do not require any
+modification to the source code that depends on the software. Source
+compatibility also implies functional compatibility, although it does
+not necessarily imply binary compatibility.
+
</p>
- <ul>
- <li>
+ <p>
+ <i>Examples:</i>
+ <font color=red>
+ TO DO: Add examples of source incompatible changes.
+ </font>
+ </p>
+ <a name="binary_compatibility"></a>
+ <h4>Binary Compatibility</h4>
+ <p>
-All issues sheduled for the release have been resolved.
+<i>Binary Compatibility</i> is the compatibility of two releases of a
+library such that one can be replaced with the other without
+requiring that dependent software be recompiled.
- </li>
- <li>
+ </p>
+ <p>
-No compilation or linker errors in the test suite (including example programs)
on Primary and Secondary target platforms.
+The binary compatibility of two releases of a shared library is
+determined by the binary size and layout of symbols such as functions,
+types, and objects, exposed directly or indirectly as part of the
+application programming interface (<a
+href="http://www.hyperdictionary.com/dictionary/Application+Program+Interface";>API</a>)
+of the library. Binary compatibility also includes functional
+compatibility, i.e., the compatibility of the behavior of the new
+release with the old release. A release of a product whose API, at
+the binary level (sometimes referred to as <a
+href="http://www.hyperdictionary.com/dictionary/Application+Binary+Interface";>ABI</a>)
+is a superset of that of another release of the same product, and
+whose behavior is compatible with that of the other release, is said
+to be binary compatible with the other release. Note that with C++
+features such as templates and inline functions, it is possible for
+binary incompatible changes to have no effect on the symbols exposed
+by the shared library binary.
- </li>
- <li>
+ </p>
-No test failures, including failed assertions, on Primary Target Platforms.
+ <a name="forward_compatibility">
+ <h4>Forward Compatibility</h3>
+ <p>
- </li>
- <li>
+A forward compatible release makes it possible for dependent software
+compiled and linked against the release to "downgrade" to the prior
+release.
+
+ </p>
+ <p>
+
+Adding new features to a library is not a forward compatible
+change since software written to take advantage of the new features
+will not function correctly or at all when the library is replaced
+with another (not necessarily prior) release not containing the
+features.
+
+ </p>
+ <p>
+ <i>Examples:</i>
+ <font color=red>
+ TO DO: Add examples of forward incompatible changes.
+ </font>
+ </p>
+ <a name="backward_compatibility"></a>
+ <h4>Backward Compatibility</h4>
+ <p>
+
+A backward compatible release makes it possible for dependent software
+compiled and linked against the previous release to upgrade to the
+compatible release without having to be recompiled.
+
+ </p>
+ <p>
+
+Changes involving the addition of new features such as new functions,
+classes, or objects, as well as the removal of undefined behavior,
+i.e., changes that have no effect on the compatibility of the new
+release of the library with software that was built with the
+previous release of the library, are said to be backward (or
+sometimes upward) compatible.
+
+ </p>
+ <p>
- No build failures on Best Effort Platforms.
+Note that sometimes, even in technical literature, the term forward
+Compatibility is misused in contexts where Backward Compatibility is
+really meant. For example, Hewlett Packard documentation uses the
+terms in the opposite sense.
+ </p>
+ <p>
+ <i>Examples:</i>
+ <font color=red>
+ TO DO: Add examples of backward incompatible changes.
+ </font>
+ </p>
+
+ <a name="references"></a>
+ <h2>References</h2>
+ <p>
+
+The following process documents were considered during the formulation
+of the Apache C++ Standard Library release guidelines.
+
+ </p>
+ <ul>
+ <li>
+ <a href="http://httpd.apache.org/dev/release.html";>
+ Apache HTTP Server Release Guidelines</a>
</li>
<li>
-
+ <a href="http://apr.apache.org/versioning.html";>
+ Apache Portable Runtime Version Numbering Concepts</a>
</li>
<li>
-
- Any outstanding test failures on Secondary Platforms are recorded in the form
of issues in the bug tracking database.
+ <a href="http://svn.boost.org/trac/boost/wiki/ImprovingPractices";>
+ Boost Development and Release Practices</a>
+ </li>
+ <li>
+ <a href="http://docs.hp.com/en/B2355-90655/index.html";>
+ HP-UX Linker and Libraries User's Guide: HP 9000 Computers</a>
+ </li>
+ <li>
+ <a href="http://docs.sun.com/app/docs/doc/817-1984";>
+ Solaris 10 Linker and Libraries Guide</a>
+ </li>
+ <li>
+ <a
href="http://techpubs.sgi.com/tpl.cgi/view/SGI_Developer/mandate_IRIX";>
+ The Mandate of Application Compatibility in SGI IRIX 6.5</a>
+ </li>
+ <li>
+ <a href="http://en.wikipedia.org/wiki/Application_binary_interface";>
+ Wikipedia: Application binary interface</a>
+ </li>
+ <li>
+ <a href="http://en.wikipedia.org/wiki/Source-compatibility";>
+ Wikipedia: Source compatibility</a>
+ <li>
+ <a href="http://en.wikipedia.org/wiki/Backward_compatibility";>
+ Wikipedia: Backward compatibility</a>
+ </li>
+ <a href="http://en.wikipedia.org/wiki/Forward_compatibility";>
+ Wikipedia: Forward_compatibility</a>
</li>
</ul>
</body>
