chore: adopt release-please for release management - #456
Merged
Conversation
CONTRIBUTING.md has claimed since July 2022 that "Release management is controlled through Release-Please". It never has been. PR #111 proposed it on 4 Jul 2022 and was closed unmerged the next day with no comments; the guide asserting it was written the day after that. This makes the claim true. Modelled on OctopusDeploy/cli, which runs this setup today at v2.23.10. goreleaser is removed rather than kept alongside: builds are already skipped in .goreleaser.yml, so it exists only to generate release notes from commit subjects, which release-please replaces. cli keeps goreleaser because it ships binaries; this repo does not. version.txt seeds the current version so release-please continues from 2.115.0 rather than starting at 1.0.0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
NickJosevski
force-pushed
the
chore/adopt-release-please
branch
from
August 19, 2026 02:19
9a5471c to
7b1c823
Compare
YuKitsune
approved these changes
Aug 20, 2026
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.
Why
CONTRIBUTING.md2022 said "Release management is controlled through Release-Please. That was a lie.changes
Before this a change's release note is its squashed commit subject — goreleaser builds notes from subject lines only, and PR bodies and commit bodies are dropped. Anything longer has to be pasted onto the GitHub Release by hand at tag time, by whoever happens to be tagging.
#435 / #452 are a live examples
Approach
like OctopusDeploy/cli
Deleting and force-pushing floating tags is harmful for a Go module — the module proxy caches tags immutably, so mutating them produces checksum mismatches for anyone who has already fetched them.
goreleaser is removed rather than kept.
.goreleaser.ymlalready setsbuilds: skip: true, so it exists purely to generate release notes, which release-please replaces. cli keeps goreleaser because it ships binaries; this repo publishes a Go module and does not.to confirm before merging
Breaking changes need a convention. The module path is
github.com/OctopusDeploy/go-octopusdeploy/v2. A singlefeat!:orBREAKING CHANGE:commit makes release-please propose 3.0.0 — but for a Go module a major bump also requires the module path to become/v3and every consumer to rewrite their imports. Release-please cannot know that.The safety valve is that it proposes a PR, and with
release-type: simplethe version lives in an editableversion.txt, so a wrong major can be corrected before merge. That only works if reviewers know to look. This is not hypothetical: #251 is a pending breaking change in the backlog.Also worth knowing
Every release will now need an approving review. Today someone just pushes a tag.