From e9750720c3d865920e7862b367f79a051beda612 Mon Sep 17 00:00:00 2001 From: Eric Hawicz Date: Sun, 18 Oct 2026 16:59:23 -0400 Subject: [PATCH] Add scripts to handle most of the first couple steps of creating a release. --- RELEASE_CHECKLIST.txt | 86 ++++++++++++++++++++++----------------- reltools/release_step1.sh | 34 ++++++++++++++++ reltools/release_step2.sh | 21 ++++++++++ 3 files changed, 103 insertions(+), 38 deletions(-) create mode 100755 reltools/release_step1.sh create mode 100755 reltools/release_step2.sh diff --git a/RELEASE_CHECKLIST.txt b/RELEASE_CHECKLIST.txt index ac886f3..5607bab 100644 --- a/RELEASE_CHECKLIST.txt +++ b/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 diff --git a/reltools/release_step1.sh b/reltools/release_step1.sh new file mode 100755 index 0000000..730b585 --- /dev/null +++ b/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 <