Context Navigation

Changes between Version 1 and Version 2 of ImprovingPractices

Timestamp:: Aug 7, 2007, 11:09:03 PM (15 years ago)
Author:: Beman Dawes
Comment:: Fix links and formating

Legend:

: Unmodified
: Added
: Removed
: Modified

ImprovingPractices

-              v1
+              v2
  * Timely Boost releases on a predictable schedule, with no possibility that problems with a few libraries can delay a release of Boost as a whole.
  * The latest [wiki:ImprovingPractices#release-ready release-ready] Boost code available from the Subversion repository at all times, including both fixes and new libraries added subsequent to the last official release. Users of this version should not have to wait for a formal release, and should not have to run the risk of instability associated with purely developmental branches.
+ * The latest [#release-ready release-ready] Boost code available from the Subversion repository at all times, including both fixes and new libraries added subsequent to the last official release. Users of this version should not have to wait for a formal release, and should not have to run the risk of instability associated with purely developmental branches.
  * Release preparation does not require super-human effort by the release manager, developers, or testers.
  * A [wiki:ImprovingPractices#stable stable] development environment is maintained at all times, with the development of any one library decoupled from development of other libraries. In particular, there is no "wild west" syndrome where the overall development environment is unstable because the current development state of one or more individual libraries is unstable.
+ * A [#stable stable] development environment is maintained at all times, with the development of any one library decoupled from development of other libraries. In particular, there is no "wild west" syndrome where the overall development environment is unstable because the current development state of one or more individual libraries is unstable.
  * Boost subset releases are both possible and reasonably easy. For example, Spirit should be able to do a release of it and its dependencies at any time the Spirit team wishes to do so. Note: This implies many of the other objectives, and may also require changes in where Boost header files live within the directory structure. Forwarding headers or links can be used so that such a change is transparent to users.
  * [wiki:ImprovingPractices#release-ready release-ready] criteria include not only regression test failures, but also inspection failures, tool-chain errors, configuration errors, missing files, and any other detectable errors that reduce release quality or impact development environment stability.
+ * [#release-ready release-ready] criteria include not only regression test failures, but also inspection failures, tool-chain errors, configuration errors, missing files, and any other detectable errors that reduce release quality or impact development environment stability.
  * Error reporting, including pestering, does not produce false positives, such as when failure for a library is due to instability in its dependencies.
 …
 == Definitions  ==
 <a name="#release-ready"><i><b>Release-ready</b></i></a> - A library or branch that passes all appropriate tests and inspections, and meets all other release criteria, such as documentation being up-to-date. Note that the requirements for being release-ready are transitive; if a library has dependent libraries, it isn't considered release-ready if it breaks any of those dependent libraries.
+'''''Release-ready''''' - A library or branch that passes all appropriate tests and inspections, and meets all other release criteria, such as documentation being up-to-date. Note that the requirements for being release-ready are transitive; if a library has dependent libraries, it isn't considered release-ready if it breaks any of those dependent libraries.
 #stable '''''Stable''''' - A library or branch that passes regression tests, but does not necessarily meet other release criteria.
+'''''Stable_''''' - A library or branch that passes regression tests, but does not necessarily meet other release criteria.
 <a name="#prerequisite-library"><i><b>Prerequisite library</b></i></a> - A library other libraries are dependent upon.
+'''''Prerequisite library''''' - A library other libraries are dependent upon.
 == Strategies ==
 …
  * The starting point for each new release is the prior release.
  * A [wiki:ImprovingPractices#release-ready release-ready] repository tree is maintained at all times.
+ * A [#release-ready release-ready] repository tree is maintained at all times.
  * Reduce the time lag between when a library developer needs fresh test results and when those results actually become available.
 …
 == Repository Organization ==
 <a name="#release-tree"><i><b>Release tree</b></i></a>  -  [wiki:ImprovingPractices#release-ready release-ready] tree into which libraries are merged after beta testing. <i>We may decide to make this tree read-only except for the release management team.</i>
+'''''Release tree'''''  -  [#release-ready release-ready] tree into which libraries are merged after beta testing. <i>We may decide to make this tree read-only except for the release management team.</i>
 :The URL for the release tree is //svn.boost.org/svn/boost/release
+ The URL for the release tree is //svn.boost.org/svn/boost/release
 <i><b>Release tags</b></i> - These are copies of the the Release Branch made by the release manager, identifying the basis for generating tarballs and such. There are two forms; one for release candidates, another for final releases.
+'''''Release tags''''' - These are copies of the the Release Branch made by the release manager, identifying the basis for generating tarballs and such. There are two forms; one for release candidates, another for final releases.
+:The URLs for release candidates are in the form <nowiki>//svn.boost.org/svn/boost/tags/Version_1_35_0_RC1</nowiki>
+ The URLs for release candidates are in the form //svn.boost.org/svn/boost/tags/Version_1_35_0_RC1
+:The URLs for final releases are in the form <nowiki>//svn.boost.org/svn/boost/Version_1_35_0</nowiki>
+ The URLs for final releases are in the form //svn.boost.org/svn/boost/Version_1_35_0
 <a name="#main-trunk"><i><b>Main trunk</b></i></a> - The main development and test location.
+'''''Main trunk''''' - The main development and test location.
 Every effort must be made to keep <a href="#prerequisite-libraries">prerequisite libraries</a> stable in the main trunk, since failures in these libraries cascade into the testing of other libraries.
+Every effort must be made to keep [#prerequisite-libraries prerequisite libraries] stable in the main trunk, since failures in these libraries cascade into the testing of other libraries.
 There is no need or obligation for non-prerequisite libraries to be stable in the main trunk, since by definition no other libraries depend on non-prerequisite libraries.
 :The URL for the main trunk is //svn.boost.org/svn/boost/trunk
+ The URL for the main trunk is //svn.boost.org/svn/boost/trunk
 <i><b>Development branches</b></i> - Location for speculative/experimental/future work on an individual library or set of libraries.
+'''''Development branches''''' - Location for speculative/experimental/future work on an individual library or set of libraries.
 :The URL for development branches is //svn.boost.org/svn/boost/branches/branch-name
+ The URL for development branches is //svn.boost.org/svn/boost/branches/branch-name
 == <a name="#development">Development Cycle</a> ==
+== Development Cycle ==
 Developers can ensure a <a href="#stable">stable</a> development environment by checking out //svn.boost.org/svn/boost/release as their working copy, and then <a href="http://svnbook.red-bean.com/en/1.1/ch04s05.html">switching</a> only the library they are working with to //svn.boost.org/svn/boost/trunk or a library specific development branch.
+Developers can ensure a [#stable stable] development environment by checking out //svn.boost.org/svn/boost/release as their working copy, and then [http://svnbook.red-bean.com/en/1.1/ch04s05.html switching] only the library they are working with to //svn.boost.org/svn/boost/trunk or a library specific development branch.
 === Merging from main trunk to release tree ===
 Only when a library update is tested and stable on trunk, and is fully [wiki:ImprovingPractices#release-ready release-ready], is it merged into the <a href="#release-tree">release tree</a>.
+Only when a library update is tested and stable on trunk, and is fully [#release-ready release-ready], is it merged into the [#release-tree release tree].
+<i>Details of when the release tree merges are acceptable and who actually does the merge are yet to be worked out. One possibility is to allow any developer to merge into the release tree at any time except immediately before a release. A "Release_candidate" tag could be maintained, and either manually or by script moved up to the head of the release tree once the newly merged library passes all tests.</i>
+''Details of when the release tree merges are acceptable and who actually does the merge are yet to be worked out. One possibility is to allow any developer to merge into the release tree at any time except immediately before a release. A "Release_candidate" tag could be maintained, and either manually or by script moved up to the head of the release tree once the newly merged library passes all tests.''
 === Special case: Prerequisite libraries ===
 <a href="#prerequisite-libraries">Prerequisite library</a> changes that run any risk of breaking libraries that depend on them should always be first applied and tested on a branch, and only merged into the main trunk when stable.
+[#prerequisite-libraries Prerequisite library] changes that run any risk of breaking libraries that depend on them should always be first applied and tested on a branch, and only merged into the main trunk when stable.
 The rationale is that changes to the main trunk that break prerequisite libraries are a serious problem because these changes destabilize the test environment for all libraries that depend on them. This causes developers of other libraries to expend needless effort tracking down test failures that aren't their fault.
 …
 === Trunk testing ===
 The <a href="#trunk">main trunk</a> is where most testing resources should be concentrated, since these tests are what tell developers that their library works on all tested platforms and tell the release management team that it is OK to merge a library into the release tree.
+The [#trunk main trunk] is where most testing resources should be concentrated, since these tests are what tell developers that their library works on all tested platforms and tell the release management team that it is OK to merge a library into the release tree.
 === Release testing ===
 In theory, it should not be necessary to test the <a href="#release-tree">release tree</a> at all, since everything merged into it should already be known to be [wiki:ImprovingPractices#release-ready release-ready].
+In theory, it should not be necessary to test the [#release-tree release tree] at all, since everything merged into it should already be known to be [#release-ready release-ready].
 In practice, the release criteria platform/compiler combinations at the minimum should be tested on the release tree. A single reliable test runner for each release criteria platform/compiler combination should be sufficient.
 …
 This Wiki page is being maintained by Beman Dawes.
 Although the details differ, the release model described here is similar to <a href="http://lists.boost.org/Archives/boost/2006/01/99522.php">proposed by Robert Ramey</a> where he suggested "Each library could be developed at its own pace and schedule."
+Although the details differ, the release model described here is similar to one [http://lists.boost.org/Archives/boost/2006/01/99522.php proposed by Robert Ramey] where he suggested "Each library could be developed at its own pace and schedule."
 Refinements of a May, 2006, draft proposal by Beman Dawes were based on comments from Michael Fawcett, Simon Carter, Arkadiy Vertleyb, Pedro Lamarão, Robert Ramey, Anthony Williams, and Thorsten Ottosen.
 Discussion during <a href="http://www.boostcon.com"><nowiki>BoostCon</nowiki> 2007</a> between Beman Dawes, Thomas Witt, Troy Straszheim, Dave Abrahams, Eric Niebler, and Doug Gregor shaped this proposal.
+Discussion during [http://www.boostcon.com BoostCon 2007] between Beman Dawes, Thomas Witt, Troy Straszheim, Dave Abrahams, Eric Niebler, and Doug Gregor shaped this proposal.
 Comments and corrections to this page were contributed by Stefan Seefeld, Peter Dimov, ...