further refine the release process

Let's try a new approach where we increment the version number
immediately after publishing a release, not just before.

This will mean that anyone who builds from git gets a version of Stow
which is higher than the release which was just cut, and this could
provide valuable debugging hints in case a bug report does not clearly
state whether the problem arose with the latest release or with a build
from git.

1 files changed, 29 insertions, 1 deletions

diff --git a/doc/HOWTO-RELEASE b/doc/HOWTO-RELEASE
index 76812df..7be57bb 100644
--- a/doc/HOWTO-RELEASE
+++ b/doc/HOWTO-RELEASE
@@ -11,9 +11,17 @@ First read the official information for maintainers of GNU software:
 Release procedure
 -----------------
 
+- Set a shell variable to the version to be released, e.g.  if the
+  final step of this document was carried out after the previous
+  release was published:
+
+    version=$( git describe --match v* --abbrev=0 )
+
 - Ensure NEWS contains the latest changes, and that any new
   contributors have been added to THANKS.
 
+- git commit -m "Prepare NEWS and THANKS for $version release"
+
 - Ensure configure.ac contains the new version number.
   This should follow Semantic Versioning as described at:
 
@@ -39,6 +47,11 @@ Release procedure
         ./Build distmeta
 
     - Check META.yaml and META.json have the new version number.
+      They already should if the final step of this document was
+      carried out after the previous release was published, but
+      if not:
+
+        git commit -m "Bump version to X.Y.Z"
 
 - Ensure all changes are committed to git.
 
@@ -47,7 +60,7 @@ Release procedure
 
 - Tag the current git HEAD with the new version number:
 
-    git tag -s v7.8.9
+    git tag -s $version -m "Release $version"
 
 - Push HEAD and tag to savannah
 
@@ -100,3 +113,18 @@ Release procedure
 
   See http://www.gnu.org/prep/maintain/html_node/Announcements.html for
   more on making release announcements.
+
+- Update the git repositories to the next expected version, so that anyone
+  who builds from git gets a version of Stow which is higher than the release
+  which was just cut:
+
+    - Increment the patchlevel of the version number in configure.ac.
+
+    - Repeat the same procedure listed in the Module::Build section
+      above, in order to update META.yaml and META.json.
+
+    - git commit -m "Bump version to X.Y.Z for development of next release"
+
+    - git push savannah
+
+    - git push github