Add scripts to handle most of the first couple steps of creating a release.

RELEASE_CHECKLIST.txt

@@ -3,8 +3,6 @@
 
 ## Pre-release tasks
 
-* Figure out whether a release is worthwhile to do.
-
 Tiny/patch releases require some manual work:
 
 * Apply changes to the release branch, merge or cherry-pick
@@ -14,48 +12,60 @@ Tiny/patch releases require some manual work:
 
 The rest of these instructions assume you're creating a minor or major release.
 
-* Load release shell functions
-    * `. reltools/reltools.subr`
-    * `set_rel_vars`
-* Analyze the previous release branch to see if anything should have been
-  applied to master.
-    * `git log -r "${RELBASE}..${RELBRANCH}" | less`
-    * Look for anything other than generating docs, bumping the release
-      version, or changes cherry-picked from master.
-* Collect changes and assemble tentative release notes.
-    * Create "Notes for v0.xx release" page at https://github.com/json-c/json-c/wiki
-    * Check commit logs between previous branch point and now for
-       notable changes worth mentioning. 
-        * `git log --reverse -r "${RELBASE}"..master | less`
-    * Create a new issues_closed_for_X.Y.md file
-        * `./reltools/gen_issues_closed.md`
-        * Include notable entries from here in the release notes.
-    * Analyze APIs between previous release branch and master to produce list of
-      changes (added/removed/updated funcs, etc...), and detect backwards compat
-      issues.
-        * https://github.com/lvc/abi-compliance-checker
-        * `./abi-check.sh`
-        * If the new release is not backwards compatible, then this is a MAJOR release.
-        * Mention removed features in ChangeLog
-		* Consider re-adding backwards compatible support, through symbol
-		  aliases and appropriate entries in json-c.sym
-		* Be sure any new symbols are listed in json-c.sym as part of
-		  the _new_ release version.
-    * Update the AUTHORS file
-        * `update_authors`
+* Figure out whether a release is worthwhile to do.
+    * `./reltools/release_step1.sh`
 
-    * Exclude mentioning changes that have already been included in a point 
-      release of the previous release branch.
+    * This will drop you in a shell and recomment git commands to:
+        * Analyze the previous release for missed patches
+        * Look for anything other than generating docs, bumping the release
+          version, or changes cherry-picked from master.
+        * Check commit logs since the previous release.
+            * Update the ChangeLog with notable changes (or defer to a later step)
 
-* Update ChangeLog with relevant notes *before* branching.
+    * Collect changes and assemble tentative release notes.
+        * Create "Notes for v0.xx release" page at https://github.com/json-c/json-c/wiki
+          to track release status and coordinate on release creation.
 
-* Check that GitHub Actions are all working - https://github.com/json-c/json-c/actions
-* Check that the compile works on Linux - automatic through Travis
-* Check that the compile works on NetBSD
-* Check that the compile works on Windows - automatic through AppVeyor
+* Yes, let's create a release:
+
+    * `./reltools/release_step2.sh`
+
+    * Update ChangeLog with relevant notes *before* branching.
+        * Exclude mentioning changes that have already been included in a point 
+          release of the previous release branch.
+
+    * Examine issues_closed_for_${NEXT_RELVER}", update ChangeLog with notable entries.
+
+    * Examine ${HOME}/abi-compliance-checker/compat_reports/json-c/...
+        * Generated by https://github.com/lvc/abi-compliance-checker
+        * Analyze APIs between previous release to produce list of
+          changes (added/removed/updated funcs, etc...), and detect backwards
+          compat issues.
+        * If the new release is not backwards compatible, then this is a MAJOR
+          release, i.e. 0.N -> 1.0.
+            * Consider re-adding backwards compatible support, through symbol
+              aliases and appropriate entries in json-c.sym
+            * Mention removed features in ChangeLog
+        * Be sure any new symbols are listed in json-c.sym as part of
+          the _new_ release version.
+
+    * Update json-c.sym to list any new symbols in the _new_ release version
+        * `release_step2.sh` will emit a summary of changes
+        * Or, examine the ABI report to identify added/removed symbols
+
+    * Examine the AUTHORS file for duplicates and other automatic update mistakes.
+
+* Check builds
+    * Check that GitHub Actions are all working - https://github.com/json-c/json-c/actions
+    * Check that the compile works on Linux - automatic through Travis
+    * Check that the compile works on NetBSD
+    * Check that the compile works on Windows - automatic through AppVeyor
 
 ## Release creation
 
+At this point, all work to update ChangeLog and other files, fix build or
+ test errors, and generally plan the release should be done.
+
 Start creating the new release:
 
     . reltools/reltools.subr

reltools/release_step1.sh

@@ -0,0 +1,34 @@
+#!/bin/bash
+#
+# Step 1 of creating a release:
+#  Determine whether a release is worth doing
+
+set -e -o pipefail
+
+RUNDIR=$(dirname "$0")
+
+. "${RUNDIR}/reltools.subr"
+set_rel_vars
+
+cat <<EOF
+RELTAG=${RELTAG}
+RELVER=${RELVER}
+RELBRANCH=${RELBRANCH}
+RELBASE=${RELBASE}
+NEXT_RELVER=${NEXT_RELVER}
+
+Analyze previous release branch to see if anything should have been
+ applied to master:
+
+git log -r "${RELBASE}..${RELBRANCH}" | less
+
+Check commit logs between previous branch point and now for notable changes.
+
+git log --reverse -r "${RELBASE}"..master | less
+
+Starting shell:
+EOF
+
+$SHELL
+
+echo "$0: done"

reltools/release_step2.sh

@@ -0,0 +1,21 @@
+#!/bin/bash
+#
+# Step 2 of creating a release:
+#  We've decided a release is worth doing
+#   Update automatic bits
+#   Collect information needed to populate changelog, etc...
+
+set -e -o pipefail
+
+RUNDIR=$(dirname "$0")
+
+cd "${RUNDIR}"
+
+./gen_issues_closed.sh
+
+../abi-check.sh
+
+./update_authors.sh
+
+./check_symbols.sh || true
+