chore: graduate to a stable release - #218
Merged
Merged
Conversation
The last release was 5.1.0-beta and release-please does not graduate on its own: the default versioning strategy keeps the prerelease suffix, so the open release PR proposed 5.1.1-beta rather than 5.1.0. Release-As applies to a single release and leaves nothing in the config, unlike the "release-as" config key which would pin every subsequent release. The footer was in #216's pull request body and did not survive. GitHub only builds a squash commit from the title and body when the branch has more than one commit; with a single commit it uses that commit's message. It is recorded in the release skill so the next person does not lose an hour to it. Release-As: 5.1.0
Merged
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 open release PR proposes
5.1.1-beta, not5.1.0.release-please does not graduate off a prerelease on its own — the default
versioning strategy keeps the suffix, so
5.1.0-betaplus afix:becomes5.1.1-beta.Release-As:in the commit message fixes it for that one release, and leavesnothing behind in the config (unlike the
release-asconfig key, which wouldpin every subsequent release to the same version).
Why it needs its own commit
I put the footer in #216's pull request body and it was dropped. GitHub only
builds a squash commit from the title and body when the branch has more than one
commit; with a single commit it uses that commit's own message.
So here the footer is in the commit message itself. This PR must keep a single
commit for that to survive — if it grows a second, the squash message comes
from this description instead, which also carries the footer, so either way it
lands.
That trap is now written into the release skill.
Answering the question directly
No, this is not needed again. It exists only to cross from
5.1.0-betato5.1.0. Once the manifest holds a stable version, release-please computes eachrelease from the conventional commits since the last one, and no footer is
involved.
What to watch after merging
The release PR should flip to
chore: release 5.1.0. Merging that is thereal test: release-please should create the draft by itself, which is what
separate-pull-requests: falsewas preventing.