docs: note v0.3.2 as first immutable release#68
Conversation
Immutable Releases is enabled at the repository level, but GitHub applies it only to releases published after the setting was flipped. Publish v0.3.2 as the first immutable tag and document in the README/CHANGELOG so users know which tag to pin for supply-chain hardening. Also bump example snippets from @v0.3.0 to @v0.3.2 and backfill the skipped v0.3.1 changelog entry. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
The ephemeral instance for the application preview has been shut down |
joe4dev
left a comment
joe4dev
left a comment
There was a problem hiding this comment.
It feel like we could benefit from some release automation to get these chores done. I remember @skyrpex introduced https://github.com/googleapis/release-please for the LocalStack Toolkit, which could automate such error-prone chores.
What's the reason for having two changelogs: a CHANGELOG.md and release notes in https://github.com/localstack/setup-localstack/releases/tag/v0.3.1 ?
We can remove the CHANGELOG.md again if we feel it's unnecessary. It might be a bit redundant as you say with the GitHub releases here. Since the plan is to rework the action anyway I'd not put too much effort for now into automation |
2 participants
Motivation
GitHub Immutable Releases is now enabled at the repo level, but GitHub only applies it to releases published after the setting was flipped —⚠️ . This PR prepares the docs for
v0.3.1and earlier remain mutablev0.3.2, which will be the first immutable tag users can pin to for supply-chain hardening.Fixes DRG-752
Changes
v0.3.2(or later).LocalStack/setup-localstack@v0.3.0references in example snippets to@v0.3.2.[0.3.2]entry inCHANGELOG.mddocumenting the immutable-release milestone.[0.3.1]entry while at it (referencing Only show use-pro deprecation message on top action input #67).Follow-ups
v0.3.2release immediately after merging so the tag is actually immutable.