Changes between Version 15 and Version 16 of ImprovingPractices
- Timestamp:
- Sep 4, 2007, 7:59:11 PM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ImprovingPractices
v15 v16 83 83 The main development and test location. 84 84 85 Every effort must be made to keep [#Prerequisitecomponent prerequisite components] stable in the main trunk, since failures in these cascade into the testing of other components.86 87 There is no need or obligation for non-prerequisite components to be stable in the main trunk, since by definition no other components depend on non-prerequisite components.85 Every effort must be made to keep the main trunk stable. Changes should tested locally by developers before they are committed to the main trunk. 86 87 Breaking changes to [#Prerequisitecomponent prerequisite components] must be coordinated with developers of dependent libraries, to ensure that changes to all affected libraries are committed to the trunk at the same time. Such multi-library changes may first require special testing against a branch before being merged into the main trunk. 88 88 89 89 The URL for the main trunk is [source:/trunk http://svn.boost.org/svn/boost/trunk] … … 102 102 103 103 The release branch is where release testing occurs. 104 105 104 106 105 The 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. … … 113 112 114 113 The URL for development branches is in the form !http://svn.boost.org/svn/boost/branches/libs/library-name 114 115 115 == Development Cycle == 116 116 117 Developers 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. 117 The policy of keeping the trunk stable is intended to ensure that the trunk is a stable environment for most development. 118 119 Developers can ensure a extra [#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. But the goal is that the trunk is stable enough that this procedure isn't usually necessary. 118 120 119 121 === Merging changes from development trunk to release branch === 120 122 121 When 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.123 When the next version of a library has been tested and is stable on the main trunk, and is fully [#Release-ready release-ready], developers are free to merge their library into the release branch as soon the release manger announce the branch is open for merging. Merging can continue until the release manager announces the release branch is closed later in the release cycle. 122 124 123 125 Detailed procedure for merging: 124 126 125 * Verify that the library meets all release criteria. '''Important:''' Libraries must not be merged into the release trunk until they are already known to be fully [#Release-ready release-ready].127 * Verify that the library meets all release criteria. '''Important:''' Libraries must not be merged into the release trunk until they are passing all trunk tests (or the failures marked-up) and are otherwise fully [#Release-ready release-ready]. 126 128 127 129 * TortoiseSVN: … … 154 156 == Testing == 155 157 156 Both development trunk and release branch testing go on continuously, a s needed,independent of when releases actually occur. Testers never have to change the repository URLs they test against.158 Both development trunk and release branch testing go on continuously, a independent of when releases actually occur. Testers never have to change the repository URLs they test against. 157 159 158 160 === Trunk testing === … … 164 166 In 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]. 165 167 166 In 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.168 In practice, the release criteria platform/compiler combinations at the 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. 167 169 168 170 == Role of the Release Manager ==