Repository navigation
chore(release): cut 0.6.0 - #897
Merged
Merged
Conversation
Rename docs/release-notes/0.6.0-pre.md to 0.6.0.md with a release date and tag header, bump the workspace version 0.6.0-rc1 -> 0.6.0 (with the satd-events-client pin on satd-events-proto and the Go SDK's Version), and collapse the changelog's [Unreleased] list into a 0.6.0 releases-table row. The release-notes index gains the 0.6.0 row, and the two illustrative version strings in the manual and the appliance README now say 0.6.0. The release workflow now compares a final tag's generated PR list with the previous final release. GitHub's default base is the latest release with pre-releases included, so v0.6.0's list would have started at v0.6.0-rc1 and named only the three PRs since. v0.1.0's list shows the same thing: it compares against v0.1.0-rc1. An -rc tag keeps GitHub's choice, and a failed lookup leaves it to GitHub as well. Not touched, as for 0.5.2: the Umbrel and StartOS image pins, which name a per-commit image digest that only exists once the tag has built it. Verified: satd --version and sat-cli --version report 0.6.0; build-release-notes.sh resolves 0.6.0.md without the -pre fallback and writes a 34,487-byte body, under its 100,000-byte guard; no reference to 0.6.0-pre.md remains; the previous-tag lookup gives v0.5.2 for v0.6.0, GitHub's default for an -rc tag, and GitHub's default when the lookup fails, without failing the step. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…say 0.6.0 The previous-tag lookup took the most recently created final release. A patch shipped on an older line after a newer release (a v0.5.3 after v0.6.0) would then have become the compare base for the next v0.6.x, and its generated PR list would have named every PR since the patch. The lookup now sorts final vX.Y.Z tags by version, adds the current tag, and takes the entry just below it. Checked against a stub list in creation order v0.5.3, v0.6.0, v0.5.2 for a v0.6.1 tag: the old lookup gave v0.5.3, the new one gives v0.6.0. The live repo still gives v0.5.2 for v0.6.0; a re-run after v0.6.0's own release exists also gives v0.5.2; v0.10.1 sorts above v0.9.x; an -rc tag, an empty list and a failed lookup all leave the choice to GitHub. The Warnet examples and README named the 0.5.2-warnet0 image while the Dockerfile comment and render-confs.sh say 0.6.0-warnet0. The CI rigs build their own satd-warnet:ci image and use their own network files, so nothing they run changes. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The build command tagged the result 0.6.0-warnet0 but still set SATD_IMAGE to ghcr.io/epochbtc/satd:0.5.2, so copying it built a 0.6.0-labelled image on a 0.5.2 base. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
bkeroack
added a commit
that referenced
this pull request
Oct 6, 2026
* chore(release): cut 0.6.0 Rename docs/release-notes/0.6.0-pre.md to 0.6.0.md with a release date and tag header, bump the workspace version 0.6.0-rc1 -> 0.6.0 (with the satd-events-client pin on satd-events-proto and the Go SDK's Version), and collapse the changelog's [Unreleased] list into a 0.6.0 releases-table row. The release-notes index gains the 0.6.0 row, and the two illustrative version strings in the manual and the appliance README now say 0.6.0. The release workflow now compares a final tag's generated PR list with the previous final release. GitHub's default base is the latest release with pre-releases included, so v0.6.0's list would have started at v0.6.0-rc1 and named only the three PRs since. v0.1.0's list shows the same thing: it compares against v0.1.0-rc1. An -rc tag keeps GitHub's choice, and a failed lookup leaves it to GitHub as well. Not touched, as for 0.5.2: the Umbrel and StartOS image pins, which name a per-commit image digest that only exists once the tag has built it. Verified: satd --version and sat-cli --version report 0.6.0; build-release-notes.sh resolves 0.6.0.md without the -pre fallback and writes a 34,487-byte body, under its 100,000-byte guard; no reference to 0.6.0-pre.md remains; the previous-tag lookup gives v0.5.2 for v0.6.0, GitHub's default for an -rc tag, and GitHub's default when the lookup fails, without failing the step. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * release: pick the previous final release by version; warnet examples say 0.6.0 The previous-tag lookup took the most recently created final release. A patch shipped on an older line after a newer release (a v0.5.3 after v0.6.0) would then have become the compare base for the next v0.6.x, and its generated PR list would have named every PR since the patch. The lookup now sorts final vX.Y.Z tags by version, adds the current tag, and takes the entry just below it. Checked against a stub list in creation order v0.5.3, v0.6.0, v0.5.2 for a v0.6.1 tag: the old lookup gave v0.5.3, the new one gives v0.6.0. The live repo still gives v0.5.2 for v0.6.0; a re-run after v0.6.0's own release exists also gives v0.5.2; v0.10.1 sorts above v0.9.x; an -rc tag, an empty list and a failed lookup all leave the choice to GitHub. The Warnet examples and README named the 0.5.2-warnet0 image while the Dockerfile comment and render-confs.sh say 0.6.0-warnet0. The CI rigs build their own satd-warnet:ci image and use their own network files, so nothing they run changes. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * docs(warnet): build the 0.6.0-warnet0 example on the 0.6.0 image The build command tagged the result 0.6.0-warnet0 but still set SATD_IMAGE to ghcr.io/epochbtc/satd:0.5.2, so copying it built a 0.6.0-labelled image on a 0.5.2 base. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
bkeroack
added a commit
that referenced
this pull request
Oct 6, 2026
* chore(release): cut 0.6.0 Rename docs/release-notes/0.6.0-pre.md to 0.6.0.md with a release date and tag header, bump the workspace version 0.6.0-rc1 -> 0.6.0 (with the satd-events-client pin on satd-events-proto and the Go SDK's Version), and collapse the changelog's [Unreleased] list into a 0.6.0 releases-table row. The release-notes index gains the 0.6.0 row, and the two illustrative version strings in the manual and the appliance README now say 0.6.0. The release workflow now compares a final tag's generated PR list with the previous final release. GitHub's default base is the latest release with pre-releases included, so v0.6.0's list would have started at v0.6.0-rc1 and named only the three PRs since. v0.1.0's list shows the same thing: it compares against v0.1.0-rc1. An -rc tag keeps GitHub's choice, and a failed lookup leaves it to GitHub as well. Not touched, as for 0.5.2: the Umbrel and StartOS image pins, which name a per-commit image digest that only exists once the tag has built it. Verified: satd --version and sat-cli --version report 0.6.0; build-release-notes.sh resolves 0.6.0.md without the -pre fallback and writes a 34,487-byte body, under its 100,000-byte guard; no reference to 0.6.0-pre.md remains; the previous-tag lookup gives v0.5.2 for v0.6.0, GitHub's default for an -rc tag, and GitHub's default when the lookup fails, without failing the step. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * release: pick the previous final release by version; warnet examples say 0.6.0 The previous-tag lookup took the most recently created final release. A patch shipped on an older line after a newer release (a v0.5.3 after v0.6.0) would then have become the compare base for the next v0.6.x, and its generated PR list would have named every PR since the patch. The lookup now sorts final vX.Y.Z tags by version, adds the current tag, and takes the entry just below it. Checked against a stub list in creation order v0.5.3, v0.6.0, v0.5.2 for a v0.6.1 tag: the old lookup gave v0.5.3, the new one gives v0.6.0. The live repo still gives v0.5.2 for v0.6.0; a re-run after v0.6.0's own release exists also gives v0.5.2; v0.10.1 sorts above v0.9.x; an -rc tag, an empty list and a failed lookup all leave the choice to GitHub. The Warnet examples and README named the 0.5.2-warnet0 image while the Dockerfile comment and render-confs.sh say 0.6.0-warnet0. The CI rigs build their own satd-warnet:ci image and use their own network files, so nothing they run changes. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * docs(warnet): build the 0.6.0-warnet0 example on the 0.6.0 image The build command tagged the result 0.6.0-warnet0 but still set SATD_IMAGE to ghcr.io/epochbtc/satd:0.5.2, so copying it built a 0.6.0-labelled image on a 0.5.2 base. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
The release commit for 0.6.0, into
release/0.6on top of rc1, #887 and #889. Once it merges,v0.6.0andclients/go/v0.6.0are tagged on the merge commit.What changes
0.6.0-rc1→0.6.0: workspaceCargo.tomlandCargo.lock, thesatd-events-clientpin onsatd-events-proto, and the Go SDK'sVersion.docs/release-notes/0.6.0-pre.md→0.6.0.mdwith the release date and tag header. The text is docs(release-notes): condense the 0.6.0 notes; refuse a release body GitHub would cut #889's condensed notes, unchanged. The index indocs/release-notes/README.mdgains the 0.6.0 row.[Unreleased]list collapses into a 0.6.0 releases-table row. The compare link moves tov0.6.0...HEAD.v0.6.0-rc1and named only the three PRs since.v0.1.0-rc1.v0.5.3afterv0.6.0) never becomes the base for the nextv0.6.x.-rctag keeps GitHub's choice, and so does a failed lookup; the step does not fail.Not in this PR
SATD_STACK_SUBNETandbridgeSubnet.release/0.6back tomaster. That is a post-tag step: stack, appliance: admit LAN clients to the TLS JSON-RPC listener #887, docs(release-notes): condense the 0.6.0 notes; refuse a release body GitHub would cut #889 and this commit, cherry-picked ontomaster.Verified
satd --versionandsat-cli --versionreport 0.6.0 from acargo build --locked --release.build-release-notes.sh --tag v0.6.0resolves0.6.0.mdwithout the-prefallback. It writes a 34,487-byte body that ends with the About footer and contains no repo-relative links.0.6.0-pre.mdremains in the tree.v0.5.2forv0.6.0(live, and on a re-run after the release exists),v0.6.0for av0.6.1when av0.5.3was created later,v0.10.0forv0.10.1, and GitHub's default for an-rctag, an empty list or a failed lookup, without failing the step.After merge
v0.6.0andclients/go/v0.6.0on the merge commit.sign-tarballs.sh v0.6.0.satd_version=0.6.0,flavor=bothandpublish=true, then runsign-tarballs.sh --images.🤖 Generated with Claude Code