summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/release.cli80
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}|