diff options
Diffstat (limited to 'doc')
-rw-r--r-- | doc/release.cli | 55 |
1 files changed, 36 insertions, 19 deletions
diff --git a/doc/release.cli b/doc/release.cli index fa208a3..7933e53 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 unbundling the release of a dependency we need to remove its +\N|When unbu ndling 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/}.| @@ -61,7 +61,7 @@ distribution from \c{etc/stage} and add the pre-distributed packages At least look for \c{@@\ TMP} \ - etc/review.sh | grep TMP + etc/review | grep TMP \ \h#review-db|Review database schema changes| @@ -85,21 +85,26 @@ distribution from \c{etc/stage} and add the pre-distributed packages \c{private/build2-packaging.txt}. \N|Maybe this should be done during queuing? Why do we release (but not - publish) these now and other dependencies later?| + publish) these now and other dependencies later? Maybe so that we can + stage them one more time?| \h#dependencies|Finalize all other dependencies| Make sure all other unreleased dependencies listed in \c{etc/stage} are - ready to be released. Effectively, the only remaining step should be to - change the version. + ready to be released (\c{NEWS}, etc). Effectively, the only remaining step + should be to change the version. Do this in the dependency order and finish each off with: \ - git pull && bdep sync -fura && bdep test -ar + git pull + bdep sync -fura && bdep test -ar \ + For some it may make sense to go straight to release; see + \l{#version-release Change to release version}. + \h#upgrade-dep|Upgrade dependencies| @@ -189,7 +194,8 @@ distribution from \c{etc/stage} and add the pre-distributed packages \h#stage-machines|Update \c{stage} \c{buildtab}s and build machines| Review \c{stage} \c{buildtab} for any configurations to drop (for example, - an intermediate version of a compiler). + an intermediate version of a compiler), classes to adjust (\c{legacy}, + \c{default}, \c{latest}, etc). Based on these changes update \c{stage} CI \c{buildtab}, which is a subset of the \c{stage} configurations (and is a base for the \c{queue}/\c{public} @@ -242,6 +248,9 @@ distribution from \c{etc/stage} and add the pre-distributed packages Test \l{https://stage.build2.org/0/ \c{stage} install scripts}, including upgrading, as described in \c{private/install/testing.txt}. + Perform necessary upgrades, if any, and test on ad hoc test machines + (\c{test-*}). + Also test \c{bootstrap-mingw.bat} and \c{bootstrap.sh} (preferably on something less mainstream like FreeBSD) since not exercised as part of install. @@ -276,6 +285,7 @@ distribution from \c{etc/stage} and add the pre-distributed packages versioning/tagging scripts are used: \ + git pull bdep release --no-open --show-push [--alpha|--beta] # review commit git push ... @@ -297,10 +307,11 @@ distribution from \c{etc/stage} and add the pre-distributed packages \li|Change \c{BUILD2_STAGE} in \c{build2/build2/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}.| + requirements in projects generated by \c{bdep-new}. \b{This must be + done if created projects use new features.}| - \li|Change version by updating (including with new modules) and then - executing: + \li|Change version by updating (including with new modules and/or new + dependencies) and then executing: \ etc/version @@ -423,6 +434,10 @@ distribution from \c{etc/stage} and add the pre-distributed packages git push \ + If queued package manifests contain new values, then the bpkg-rep-publish + script will fail to create repository duu to unknown manifest values. To + resolve this we temporarily add (to \c{crontab}) \c{--ignore-unknow}. + \h#build-public|Verify queued packages build with \c{public}| This makes sure that the new version can be built with the old toolchain. @@ -492,7 +507,8 @@ distribution from \c{etc/stage} and add the pre-distributed packages Adjust \c{stage} and \c{devel} build host configurations to disable the \c{queue} toolchain (comment out). Regenerate affected configurations and - reboot build hosts as on the previous step. + reboot build hosts as on the previous step (or poweroff until stage + reopening). \h1#public|Public| @@ -520,8 +536,8 @@ distribution from \c{etc/stage} and add the pre-distributed packages one for \c{stage}. Comment out the \c{public} toolchain in the build host configuration - (effectively making it a no-toolchain configuration) and power on the new - set of \c{public} build hosts. + (effectively making it a no-toolchain configuration), regenerate, and power + on the new set of \c{public} build hosts. Review deployed machines against the updated \c{public} \c{buildtab} and remove those that are no longer used: @@ -546,8 +562,8 @@ distribution from \c{etc/stage} and add the pre-distributed packages ~/work/build2/buildos/upload-machine <host> .../new-ver .../old-ver \ - Uncomment the \c{public} toolchain in the build host configuration. The - only remaining step is to reboot (not yet): + Uncomment the \c{public} toolchain in the build host configuration and + regenerate. The only remaining step is to reboot (not yet): \ ./po-hosts -r -c public @@ -555,9 +571,9 @@ distribution from \c{etc/stage} and add the pre-distributed packages \h#pub-dist|Publish distribution| - Change \c{BUILD2_REPO} in \c{build2-toolchain} build scripts to \c{public} - and publish the distribution (this also cleans/disables the \c{queue} - toolchain): + Change \c{BUILD2_REPO} in \c{build2-toolchain} build scripts to \c{public}, + commit, and publish the distribution (this also cleans/disables the + \c{queue} toolchain): \ etc/stage -p @@ -574,7 +590,8 @@ distribution from \c{etc/stage} and add the pre-distributed packages push both \c{queue} and \c{public} \c{git} repositories. Note that once published, the existing install instructions/download - links are no longer usable, so do not linger. + links are no longer usable, so do not linger (in fact, may make sense + to update Download and Install pages before publishing packages). \h#start-public|Start \c{public} builds| |