diff options
author | Boris Kolpackov <boris@codesynthesis.com> | 2019-11-20 16:56:28 +0200 |
---|---|---|
committer | Boris Kolpackov <boris@codesynthesis.com> | 2019-11-20 16:56:28 +0200 |
commit | f07e14f7cc43baf76fd6916a85be5bf2b42c531a (patch) | |
tree | 725e31d32216b41469461a6c72bdaf573af25772 /doc | |
parent | 35219dcea1530755fc37713a70d49322ec169f48 (diff) |
Updates for 0.12.0 releasev0.12.0
Diffstat (limited to 'doc')
-rw-r--r-- | doc/release.cli | 81 |
1 files changed, 59 insertions, 22 deletions
diff --git a/doc/release.cli b/doc/release.cli index 66eaebd..3f716da 100644 --- a/doc/release.cli +++ b/doc/release.cli @@ -31,7 +31,7 @@ and then be queued and published (effectively released) as part of the bundle the release of dependencies with the release of \c{build2} to keep the process as streamlined as possible. -\N|When unbu ndling the release of a dependency we need to remove its +\N|When unbundling the release of a dependency we need to remove its distribution from \c{etc/stage} and add the pre-distributed packages (for example, from \c{public}) to \c{staging/repository/1/}.| @@ -150,7 +150,8 @@ distribution from \c{etc/stage} and add the pre-distributed packages \h#doc|Review documentation| Review the following documentation for (1) sample output changes and (2) - still being relevant/making sense. + still being relevant/making sense. Also (3) check the \c{NEWS} files for + anything new worth mentioning. \N|Ideally this should be done during development but it's easy to forget. Also, check if there is any new documentation that has been added that is @@ -160,7 +161,7 @@ distribution from \c{etc/stage} and add the pre-distributed packages \li|Install guide: 1 & 2.| - \li|Toolchain introduction: 1 & 2 (use \c{intro} script output).| + \li|Toolchain introduction: 1, 2 & 3 (use \c{intro} script output for 2).| \li|Introduction in the build system manual: 1 (uses \c{bdep-new(1)} output).| @@ -232,13 +233,35 @@ distribution from \c{etc/stage} and add the pre-distributed packages Review \c{staging/0/} and \c{staging/repository/1/} for anything stray. - Restage with \c{baseutils}/\c{mingw} regeneration: + If no upgrade is possible from the previous version, uncomment errors in + install scripts (and add a note to restore after the release). - \ - etc/stage -b - \ + Restage and upgrade \c{brep} by performing the following steps: + + \ol| + + \li|Disable building of all repositories on \c{stage} by adding the + \c{buildable:no} field at the end of each line in \c{loadtab}.| + + \li|Restage with \c{baseutils}/\c{mingw} regeneration: + + \ + etc/stage -b + \ + + | - Upgrade \c{brep} on \c{stage} and sync latest \c{buildtab}s. + \li|While build machines are bootstrapping, upgrade \c{brep} on \c{stage}, + sync latest \c{buildtab}s but do not restart the web server.| + + \li|Once all build machines have bootstrapped, enabling build of all + repositories and restart the web server. To check bootstrap progress: + + \ + ./ls-machines -b stage -c stage -c devel + \ + + || Verify \c{stage} build is clean, nothing is unbuilt. @@ -304,11 +327,15 @@ distribution from \c{etc/stage} and add the pre-distributed packages \li|Close schema versions in \c{bpkg}, \c{bdep}, and \c{brep}.| - \li|Change \c{BUILD2_STAGE} in \c{build2/build2/config.hxx.in} to \c{false}.| + \li|Change \c{LIBBUILD2_STAGE} in \c{build2/libbuild2/config.hxx.in} to \c{false}.| \li|If necessary, update minimum \c{build2} and \c{bpkg} version requirements in projects generated by \c{bdep-new}. \b{This must be - done if created projects use new features.}| + done if created projects use new features.} + + \N|Why shouldn't we always do this for simplicity? Maybe because then + we cannot run tests using \c{public} services? Also the below upgrade + steps will break since there is no continuity.|| \li|Change version by updating (including with new modules and/or new dependencies) and then executing: @@ -319,6 +346,9 @@ distribution from \c{etc/stage} and add the pre-distributed packages git -C build2-toolchain commit --amend # \"Change version to X.Y.Z\" \ + Note that \c{libbuild2-hello} is independently versioned but may still + need to update minimum \c{build2} version requirements (see below). + | \li|Tag by executing \c{tag.sh\ <version>}.| @@ -360,13 +390,18 @@ distribution from \c{etc/stage} and add the pre-distributed packages BDEP_SYNC=0 b ~/work/build2/builds/gcc7-asan/ \ - || + | + + + \li|Update \c{libbuild2-hello} if required.|| Verify key tests pass (in particular, the \c{bdep} tests will now be running against \c{public} services): \ b test: build2/ bpkg/ bdep/ + b test: bpkg/ config.bpkg.test.remote=true + b test: libbuild2-hello/libbuild2-hello-tests/ \ \N|We could have queued after this step before preparing @@ -397,8 +432,8 @@ distribution from \c{etc/stage} and add the pre-distributed packages \li|Regenerate documentation in each package inside as well as in \c{build2-toolchain} itself.| - \li|Update ODB by copying relevant files from the previous step (trust - me, this is the easy way). Make sure all \c{*-odb.*} are copied!| + \li|Update ODB by copying relevant files from the previous step (trust me, + this is the easy way for now). Make sure all \c{*-odb.*} are copied!| \li|Change \c{BUILD2_REPO} in \c{build2-toolchain} build scripts to \c{queue}.|| @@ -436,7 +471,8 @@ distribution from \c{etc/stage} and add the pre-distributed packages If queued package manifests contain new values, then the bpkg-rep-publish script will fail to create repository due to unknown manifest values. To - resolve this we temporarily add (to \c{crontab}) \c{--ignore-unknown}. + resolve this we temporarily add (to \c{crontab}) \c{--ignore-unknown} and + make a note to restore. \h#build-public|Verify queued packages build with \c{public}| @@ -483,17 +519,15 @@ distribution from \c{etc/stage} and add the pre-distributed packages \c{queue} builds. As a result, after this update, \c{public} build hosts may not have some of the new (or renamed) build machines.| - Adjust \c{stage} and \c{devel} build host configurations to enable the - \c{queue} toolchain. Shift most instances from \c{stage} to \c{queue} - in the hardware class-specific configurations. Regenerate affected - configurations and reboot build hosts: + Adjust \c{stage} and \c{devel} build host configurations (both \c{*-config} + and hardware classes) to enable the \c{queue} toolchain. Shift most + instances from \c{stage} to \c{queue} in the hardware class-specific + configurations. Regenerate affected configurations and reboot build hosts: \ cd private/buildos/ - ./gen-config stage <class> - ./gen-config devel <class> - + ./regen ./po-hosts -r -c stage -c devel \ @@ -550,6 +584,8 @@ distribution from \c{etc/stage} and add the pre-distributed packages ~/work/build2/buildos/remove-machine <host> <machine> \ + Then move now legacy machines to the \"legacy\" build host. + Also review deployed machines against the latest available versions and upgrade those that are not the latest: @@ -591,7 +627,8 @@ distribution from \c{etc/stage} and add the pre-distributed packages Note that once published, the existing install instructions/download links are no longer usable, so do not linger (in fact, may make sense - to update Download and Install pages before publishing packages). + to update Download and Install pages before publishing packages and + sync only them immediately after). \h#start-public|Start \c{public} builds| |