Changes between Version 9 and Version 10 of ImprovingPractices


Ignore:
Timestamp:
Aug 23, 2007, 8:03:54 PM (15 years ago)
Author:
Beman Dawes
Comment:

Refine repository structure based on list comments

Legend:

Unmodified
Added
Removed
Modified

  • ImprovingPractices

    v9 v10  
    5555
    5656{{{
    57 //svn.boost.org/svn/boost/trunk/ (boost-root)
    58                           branches/ (branch-name) / (content)
    59                           tags/ (tag-name / (content)
    60                           release/trunk/ (boost-root)
    61                                   tags/ (tag-name / (boost-root)
     57//svn.boost.org/svn/boost/
     58
     59                       trunk
     60
     61                       tags/
     62                          ...
     63                          release/
     64                             ...
     65                             1_34_1
     66                             1_35_0
     67                     
     68                       branches/
     69                          release
     70                          libs/
     71                             ...
     72                             python
     73                             serialization
     74                             ...
    6275}}}
    6376
    64 ==== ''Main trunk'' ====
    65  The main development and test location.
     77==== ''Trunk'' ====
     78The main development and test location.
    6679
    67  Every effort must be made to keep [#Prerequisitelibrary prerequisite libraries] stable in the main trunk, since failures in these libraries cascade into the testing of other libraries.
     80Every effort must be made to keep [#Prerequisitelibrary prerequisite libraries] stable in the main trunk, since failures in these libraries cascade into the testing of other libraries.
    6881
    69  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.
     82There 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.
    7083
    71  The URL for the main trunk is [source:/trunk http://svn.boost.org/svn/boost/trunk]
     84The URL for the main trunk is [source:/trunk http://svn.boost.org/svn/boost/trunk]
     85
     86==== ''Release tags'' ====
     87 
     88These are copies of the the release branch made by the release manager, identifying the basis for generating tarballs and such. These copies are locked so that they aren't inadvertently modified.
     89
     90The URLs for release candidates are in the form !http://svn.boost.org/svn/boost/tags/release/RC_1_35_0_n
     91
     92The URLs for final releases are in the form !http://svn.boost.org/svn/boost/tags/release/1_35_0
     93
     94==== ''Release branch'' ====
     95
     96The [#Release-ready release-ready] branch of Boost that will become the next release. Library changes from the trunk are merged into this branch when an update for the library is [#Release-ready release-ready].
     97
     98The release branch is where release testing occurs.
     99
     100 
     101The release branch is under the control of the release manager. The release manager sets the policies for when and by whom updated libraries can be merged into the release branch, and may set locks and permissions on the release branch to enforce those policies. The policies will vary at different points of time during the release cycle.
     102 
     103The URL for the release branch is http://svn.boost.org/svn/boost/branches/release
    72104
    73105==== ''Development branches'' ====
    74  Location for speculative/experimental/future work on an individual library or set of libraries.
    75106
    76  The URL for development branches is in the form !http://svn.boost.org/svn/boost/branches/branch-name
     107Location for speculative/experimental/future work on an individual library or set of libraries.
    77108
    78 ==== ''Release tree'' ====
    79 
    80 The release tree is the domain of the release manager. The release manager sets the policies for when and by whom updated libraries can be merged into the release trunk, and may set locks and permissions on the release tree to enforce those policies. The policies will vary at different points of time during the release cycle.
    81  
    82 ===== ''Release trunk'' =====
    83  The boost-root that will become the next release of Boost. This is where a library is merged when an update for the library is [#Release-ready release-ready].
    84 
    85  The URL for the release trunk is http://svn.boost.org/svn/boost/release/trunk
    86 
    87 ===== ''Release tags'' =====
    88  These are copies of the the Release tree 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.
    89 
    90  The URLs for release candidates are in the form !http://svn.boost.org/svn/boost/release/tags/RC_1_35_0_n
    91 
    92  The URLs for final releases are in the form !http://svn.boost.org/svn/boost/release/tags/1_35_0
    93 
     109The URL for development branches is in the form !http://svn.boost.org/svn/boost/branches/libs/library-name
    94110== Development Cycle ==
    95111
    96 Developers can ensure a [#Stable stable] development environment by checking out [source:/release/trunk http://svn.boost.org/svn/boost/release/trunk] 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 [source:/trunk http://svn.boost.org/svn/boost/trunk] or a library specific development branch.
     112Developers can ensure a [#Stable stable] development environment by checking out [source:/release/trunk http://svn.boost.org/svn/boost/branch/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 [source:/trunk http://svn.boost.org/svn/boost/trunk] or a library specific development branch.
    97113
    98 === Merging from development trunk to release trunk ===
     114=== Merging changes from development trunk to release branch ===
    99115
    100 When the next version of a library has been tested and is stable on the main trunk, and is fully [#Release-ready release-ready], it is merged into the release trunk.
     116When the next version of a library has been tested and is stable on the main trunk, and is fully [#Release-ready release-ready], changes to it can be merged into the release trunk.
    101117
    102118Detailed procedure for merging:
    … …  
    105121
    106122 * TortoiseSVN:
    107    * Start with a working copy of https://svn.boost.org/svn/boost/release/trunk.
     123   * Start with a working copy of https://svn.boost.org/svn/boost/branches/release.
    108124   * Select the directory and/or files to be merged.
    109125   * Right-click selection for context menu, and TortoiseSVN > Merge...
    110      * From: https://svn.boost.org/svn/boost/release/trunk/...
    111      * From: Head revision
     126     * From: https://svn.boost.org/svn/boost/branches/release/...
    112127     * To: '''Uncheck''' the Use "From:" URL checkbox.
    113128     * To: https://svn.boost.org/svn/boost/trunk/...
    … …  
    134149== Testing ==
    135150
    136 Both development trunk and trunk testing go on continuously, if needed, independent of when releases actually occur. Testers never have to change the repository URLs they test against.
     151Both development trunk and release branch testing go on continuously, as needed, independent of when releases actually occur. Testers never have to change the repository URLs they test against.
    137152
    138153=== Trunk testing ===
    139154
    140 The [#Maintrunk 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.
     155The [#Maintrunk 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 branch.
    141156
    142 === Release trunk testing ===
     157=== Release branch testing ===
    143158
    144 In theory, it should not be necessary to test the release trunk at all, since everything merged into it should already be known to be [#Release-ready release-ready].
     159In theory, it should not be necessary to test the release branch at all, since everything merged into it should already be known to be [#Release-ready release-ready].
    145160
    146 In practice, the release criteria platform/compiler combinations at the minimum should be tested on the release trunk. A single reliable test runner for each release criteria platform/compiler combination may be sufficient, but that's up to the release manager to decide.
     161In practice, the release criteria platform/compiler combinations at least must be tested on the release branch. A single reliable test runner for each release criteria platform/compiler combination may be sufficient, but that's up to the release manager to decide.
    147162
    148163== Role of the Release Manager ==
    149164
    150 The release manager has the responsability of generating a timely high-quality release.
     165The release manager has the responsibility of generating a timely high-quality release.
    151166
    152167The release manager has the authority to make all critical decisions about releases, including setting release criteria, release cycle timing, revisions of problem libraries to prior versions, and all other release related decisions.
    … …  
    162177Discussion during [http://www.boostcon.com BoostCon 2007] between Beman Dawes, Thomas Witt, Troy Straszheim, Dave Abrahams, Eric Niebler, and Doug Gregor shaped this proposal.
    163178
    164 Comments and corrections to this page were contributed by Stefan Seefeld, Peter Dimov, Rene Rivera, Robert Ramey, Michael Caisse, Nicola Musatti, ...
     179Comments and corrections to this page were contributed by Stefan Seefeld, Peter Dimov, Rene Rivera, Robert Ramey, Michael Caisse, Nicola Musatti, Dave Abrahams, John Maddock, ...
    165180
    166181----