doc: make sure v prefix is always on the version.
What the developer wrote
Authored by Rusty Russell
doc: make sure v prefix is always on the version.
1. Put v prefix before NEW_VERSION
2. Change the checkin line to a one-liner.
3. Have build-release.sh check for the v prefix (with --force-version= you could omit it).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
What changed, and why it matters
This commit is a documentation and release-script hardening change. It ensures that version numbers used during Core Lightning releases always start with the letter 'v' (for example, v23.05 instead of 23.05). It updates the release checklist instructions and adds a safety check in the build-release.sh script that exits with an error if the version is missing the 'v' prefix. There is no security vulnerability being fixed here.
No security action needed. Treat as normal maintenance/process improvement.
Security signals we found
No security-relevant code changes
No vulnerability pattern present
Process/documentation hardening only
Evidence from the diff
The patch modifies two files: (1) doc/contribute-to-core-lightning/release-checklist.md, where examples of make update-versions NEW_VERSION=… are changed to include a leading ‘v’, and the tagging commands are collapsed into a one-liner; and (2) tools/build-release.sh, where a case statement is added to validate that the VERSION variable begins with ‘v’ and aborts otherwise. This is a process/QA improvement to prevent inconsistent release versioning, not a code security fix.
Changed components
doc/contribute-to-core-lightning/release-checklist.mdtools/build-release.shInspect captured patch +13 / −5
diff --git a/doc/contribute-to-core-lightning/release-checklist.md b/doc/contribute-to-core-lightning/release-checklist.md
index 624df560..29da107d 100644
--- a/doc/contribute-to-core-lightning/release-checklist.md
+++ b/doc/contribute-to-core-lightning/release-checklist.md
@@ -24,7 +24,7 @@ Here's a checklist for the release process.
2. Use `devtools/changelog.py` to collect the changelog entries from pull request commit messages and merge them into the manually maintained `CHANGELOG.md`. This does API queries to GitHub, which are severely
ratelimited unless you use an API token: set the `GH_TOKEN` environment variable to a Personal Access Token from <https://github.com/settings/tokens>
3. Create a new CHANGELOG.md heading to `v<VERSION>rc1`, and create a link at the bottom. Note that you should exactly copy the date and name format from a previous release, as the `build-release.sh` script relies on this.
-4. Update the package versions: `make update-versions NEW_VERSION=<VERSION>rc1`
+4. Update the package versions: `make update-versions NEW_VERSION=v<VERSION>rc1`
5. Create a PR with the above.
## Releasing -rc1
@@ -46,7 +46,7 @@ Here's a checklist for the release process.
## Releasing -rc2, ..., -rcN
1. Update CHANGELOG.md by changing rc(N-1) to rcN. Update the changelog list with information from newly merged PRs also.
-2. Update the package versions: `make update-versions NEW_VERSION=<VERSION>rcN`
+2. Update the package versions: `make update-versions NEW_VERSION=v<VERSION>rcN`
3. Add a PR with the rcN.
4. Tag it `git pull && git tag -s v<VERSION>rcN && git push --tags`
5. Draft a new `v<VERSION>rcN` pre-release on Github, upload reproducible builds, `SHA256SUMS-v<VERSION>` and `SHA256SUMS-v<VERSION>.asc`.
@@ -57,12 +57,11 @@ Here's a checklist for the release process.
## Tagging the Release
1. Update the CHANGELOG.md; remove -rcN in both places, update the date and add title and namer.
-2. Update the contrib/pyln package versions: `make update-versions NEW_VERSION=<VERSION>`
+2. Update the contrib/pyln package versions: `make update-versions NEW_VERSION=v<VERSION>`
3. Add a PR with that release.
4. Merge the PR, then:
- - `export VERSION=23.05`
- `git pull`
- - `git tag -a -s v${VERSION} -m v${VERSION}`
+ - `VERSION=23.05; git tag -a -s v$VERSION -m v$VERSION`
- `git push --tags`
5. Run `tools/build-release.sh` (with `--sudo` if you need root to run Docker) to:
- Create reproducible zipfile
diff --git a/tools/build-release.sh b/tools/build-release.sh
index 673bea70..1098f313 100755
--- a/tools/build-release.sh
+++ b/tools/build-release.sh
@@ -87,6 +87,15 @@ if [ "$VERSION" = "" ]; then
exit 1
fi
+# Don't forget the v prefix!
+case "$VERSION" in
+ v*) ;;
+ *)
+ echo "Version must begin with v! Not $VERSION" >&2
+ exit 1
+ ;;
+esac
+
# `status --porcelain -u no` suppressed modified! Bug reported...
if [ "$(git diff --name-only)" != "" ] && ! $FORCE_UNCLEAN; then
echo "Not a clean git directory" >&2
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.