contrib: change release procedure, to avoid reusing tags#10747
Draft
SomberNight wants to merge 3 commits into
Draft
contrib: change release procedure, to avoid reusing tags#10747SomberNight wants to merge 3 commits into
SomberNight wants to merge 3 commits into
Conversation
the download page template has not been using them for 5 years, since: spesmilo/electrum-web@3f2e8d3
to have access to name of distributable, not just as part of full URL
Towards making git tags immutable... Let's avoid reusing tags and ambiguous binary names. Problem: it happened several times during releases that we had to "cancel" a release at the last minute, after there already was a git tag, after we already built binaries, and sometimes even after those binaries were publicly available on download.electrum.org, but always before running release_www.sh (so before the main webserver linked to them or before qt gui update notifications were triggered). At almost any point during making a release we might notice that we cannot reproduce some distributables, meaning we have to cancel the release. In our current workflow, very early in the process we create a git tag, e.g. "4.8.0". If we have to cancel the release and apply some fixes, we will need a new git tag, and in that case historically we have deleted and reused git tags (so the second attempt would also be from a git tag named "4.8.0" but now pointing to a new commit). This is bad practice. We should aim to have immutable git tags. The idea here is: - construct binary name from: version.py::ELECTRUM_VERSION + git commit hash (independent of the tag) - when we build, only create an "-rc1" git tag, e.g. "4.8.0-rc1" - after we are satisfied to finalise the release, near the very end, create another git tag, e.g. "4.8.0", pointing to the same commit - so in the typical happy path, we will have two git tags: - "4.8.0-rc1" == commit1 - "4.8.0" == commit1 - if something goes wrong and we have to retry, we will have: - "4.8.0-rc1" == commit1 - "4.8.0-rc2" == commit2 - "4.8.0" == commit2
SomberNight
commented
Jul 10, 2026
Comment on lines
53
to
61
| cat <<EOF > "$WWW_DIR"/version | ||
| { | ||
| "version": "$VERSION", | ||
| "version": "$VERSIONB", | ||
| "signatures": {"$ELECTRUM_SIGNING_ADDRESS": "$sig"}, | ||
| "extradata": { | ||
| "android_versioncode_nullarch": $ANDROID_VERSIONCODE_NULLARCH | ||
| } | ||
| } | ||
| EOF |
Member
Author
There was a problem hiding this comment.
perhaps we should also put VERSIONC in the version announcement file, e.g. in extradata
Comment on lines
32
to
+36
| sftp -oBatchMode=no -b - "$SSHUSER@uploadserver" << ! | ||
| cd electrum-downloads-airlock | ||
| -mkdir "$VERSION" | ||
| -chmod 777 "$VERSION" | ||
| cd "$VERSION" | ||
| -mkdir "$VERSIONB" | ||
| -chmod 777 "$VERSIONB" | ||
| cd "$VERSIONB" |
Member
Author
There was a problem hiding this comment.
Perhaps we should also name the folder VERSIONC.
That would help f-droid, which is programmatically constructing download URLs, with a limited API.
ref https://f-droid.org/docs/Build_Metadata_Reference/#build_binary
Member
There was a problem hiding this comment.
note: with the current PR, nothing seems to clean up the airlock. If we need to change the commit for a given version number, the old file with the old commit name will remain in the airlock forever.
SomberNight
marked this pull request as draft
July 10, 2026 23:02
Member
Author
|
(edited the OP to clarify the goal is not only "immutable git tags" but also "immutable distributable names") |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Towards making git tags immutable...
Let's avoid reusing tags and ambiguous binary names.
Problem: it happened several times during releases that we had to "cancel" a release
at the last minute, after there already was a git tag, after we already built binaries,
and sometimes even after those binaries were publicly available on download.electrum.org,
but always before running
release_www.sh(so before the main webserver linked to themor before qt gui update notifications were triggered).
At almost any point during making a release we might notice that we cannot reproduce
some distributables, meaning we have to cancel the release. In our current workflow,
very early in the process we create a git tag, e.g. "4.8.0". If we have to cancel
the release and apply some fixes, we will need a new git tag, and in that case historically
we have deleted and reused git tags (so the second attempt would also be from a git tag named "4.8.0" but now pointing to a new commit). This is bad practice. We should aim
to have immutable git tags.
The idea here is:
construct binary name from:
version.py::ELECTRUM_VERSION + git commit hash
(independent of the tag)
when we build, only create an "-rc1" git tag, e.g. "4.8.0-rc1"
after we are satisfied to finalise the release, near the very end,
create another git tag, e.g. "4.8.0", pointing to the same commit
so in the typical happy path, we will have two git tags:
if something goes wrong and we have to retry, we will have: