Repository navigation
ci: open release PRs automatically from conventional commits - #474
Merged
Merged
Conversation
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This branch was successfully deployed
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
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.
A release only starts when someone runs the Release workflow by hand and picks patch, minor or major. Nothing keeps a release PR open between releases, so it's easy to lose track of what has landed since the last version.
The Release workflow now also runs on every push to
main. Release Please keeps one release PR open and picks the version from conventional commits since the last tag:fixandperfmake a patch release,featmakes a minor release, and breaking changes make a major release. The workflow commits the regeneratedbun.lockand Podfile.lock files to that PR as before. Merging the PR creates the draft release and tag on the next push run, which then runs the full release checks, publishes both packages, attaches the APK and publishes the GitHub release.The manual run is unchanged and still covers exact versions, maintenance branches, announcements and
release_tagresumes. The APK and announcement jobs now check thatpublishsucceeded instead of relying on the implicit success check. A skippedmergejob earlier in the chain made that check skip them after the 10.2.0 resume run, and the push path would hit the same problem.🤖 Generated with Claude Code