stdcxx-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From se...@apache.org
Subject svn commit: r594420 - /incubator/stdcxx/site/releases.html
Date Tue, 13 Nov 2007 03:56:40 GMT
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  <sebor@roguewave.com>

	* 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&#64;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>&lt;major&gt;.&lt;minor&gt;.&lt;micro></tt> or, optionally,
+<tt>&lt;major&gt;.&lt;minor&gt;.&lt;micro&gt;.&lt;patch&gt;</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&#64;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&#64;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>



Mime
View raw message