Updates for 0.14.0 releasev0.14.0

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}|