diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/release.cli | 80 |
1 files changed, 52 insertions, 28 deletions
diff --git a/doc/release.cli b/doc/release.cli index 17bc043..830dbab 100644 --- a/doc/release.cli +++ b/doc/release.cli @@ -65,7 +65,7 @@ distribution from \c{etc/stage} and add the pre-distributed packages \h#review|Review \c{@@}| - Review \c{@@} notes: + Review \c{etc/review} for new modules. Then review \c{@@} notes: \ etc/review | less -R @@ -175,7 +175,7 @@ distribution from \c{etc/stage} and add the pre-distributed packages \ul| - \li|Install guide: 1 & 2 (also review build2-toolchain commit log).| + \li|Install guide: 1 & 2 (also review \c{build2-toolchain} commit log).| \li|Toolchain introduction: 1, 2 & 3 (use \c{intro} script output for 2).| @@ -339,7 +339,7 @@ distribution from \c{etc/stage} and add the pre-distributed packages \ git pull bdep release --no-open --show-push [--alpha|--beta] - # review commit + # review commit, run update (in case anything comitted is pre-generated) git push ... \ @@ -363,36 +363,52 @@ distribution from \c{etc/stage} and add the pre-distributed packages 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.|| + we cannot run tests using \c{public} services? - \li|Change version by updating (including with new modules and/or new - dependencies) and then executing: + Also if we change this in toolchain packages, the below upgrade steps + will break since there is no continuity. Perhaps do it in two stages: + first change version to final, upgrade, then change toolchain + dependencies to final, upgrade again? But then nobody involed in + development will be able to pull and upgrade. Maybe KISS and keep + it pre-release.|| - \ - etc/version - ./commit.sh - git -C build2-toolchain commit --amend # \"Change version to X.Y.Z\" - \ + \li|Change version by updating \c{etc/version} (including with new modules + and/or new dependencies, but keep pre-release in minimum toolchain + version requirements) and then executing: - Note that \c{libbuild2-*} modules (e.g., \c{libbuild2-hello}) are - independently versioned but may still need to update minimum \c{build2} - version requirements (see below). + \ + etc/version + ./commit.sh + git -C build2-toolchain commit --amend # \"Change version to X.Y.Z\" + \ - | + Note that \c{libbuild2-*} modules (e.g., \c{libbuild2-hello}) are + independently versioned but may still need to update minimum toolchain + version requirements (see below).| \li|Tag by executing \c{tag.sh\ <version>}.| - \li|Regenerate documentation in each package.| + + \li|Release all standard pre-installed build system modules. Update + minimum toolchain version requirements. + + \ + bdep release --no-open --show-push + \ + + | + + \li|Regenerate documentation in each package (including standard + pre-installed build system modules, use \c{BDEP_SYNC=0}).| \li|Upgrade all dependencies in configure-only mode by executing \c{etc/upgrade\ -c}. - If the \c{build2}/\c{bpkg} requirements in the manifests have been - bumped to the version being released, then first bootstrap the build - system and update \c{bpkg}/\c{bdep} (might have to hack their - generated \c{version.hxx} to disable constraint checking; also if you - forget \c{BDEP_SYNC=0} it will most likely hose the build + Avoid this (see above): If the \c{build2}/\c{bpkg} requirements in the + manifests have been bumped to the version being released, then first + bootstrap the build system and update \c{bpkg}/\c{bdep} (might have to + hack their generated \c{version.hxx} to disable constraint checking; + also if you forget \c{BDEP_SYNC=0} it will most likely hose the build configuration). \ @@ -432,12 +448,16 @@ distribution from \c{etc/stage} and add the pre-distributed packages \ BDEP_SYNC=0 b ~/work/build2/builds/gcc7-asan/ + + b build2/ bpkg/ bdep/ + + # Update standard pre-installed build system modules. \ | - \li|Update \c{libbuild2-*} modules if required.|| + \li|Update other \c{libbuild2-*} modules if required.|| Verify key tests pass (in particular, the \c{bdep} tests will now be running against \c{public} services): @@ -446,6 +466,8 @@ distribution from \c{etc/stage} and add the pre-distributed packages b test: build2/ bpkg/ bdep/ b test: bpkg/ config.bpkg.test.remote=true b test: libbuild2-hello/libbuild2-hello-tests/ + + # Test standard pre-installed build system modules. \ \N|We could have queued after this step before preparing @@ -460,6 +482,8 @@ distribution from \c{etc/stage} and add the pre-distributed packages \ ./push.sh + # Push (with tags) standard pre-installed build system modules. + cd build2-toolchain git submodule update --remote --checkout @@ -479,7 +503,7 @@ distribution from \c{etc/stage} and add the pre-distributed packages \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 + \li|Change \c{build2_repo} in \c{build2-toolchain} \c{buildfile} to \c{queue}.|| Finally, push the changes: @@ -514,10 +538,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 due to unknown manifest values. To - resolve this we temporarily add (to \c{crontab}) \c{--ignore-unknown} and - make a note to restore. + If queued package manifests contain new values, then the + \c{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} and make a note to restore. \h#build-public|Verify queued packages build with \c{public}| |