-
-
Notifications
You must be signed in to change notification settings - Fork 915
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use release-please
workflow for managing releases
#636
Comments
Awesome! I like the idea that we can still control when to release through the CL. So feel free to introduce this here as well! The biggest challenge I see at the moment though is that we would like to pack quite a few breaking changes into the next 9.0 release, but at least I personally hardly find spare time at the moment to invest into these changes… unfortunately as long as we don’t maintain several major version branches (which is also a hassle an likely doesn’t work well with automation) the fact that we have started merging these breaking changes into main also blocks merging non-breaking perf and cleanup fixes…. But again, this is something that hardly any tooling will solve for us. |
I think we can specify which branch(es) it runs on. So we could have release PRs going for both the |
After re-reading my previous comment I no longer agree with what I've written last time ;). I think we should focus on the main branch and simply use semantic versioning to progress this project. The only event that I can think of where we would have to patch older major releases would be some sort of critical security vulnerability. And in that case I guess that irrespective of what automation we have in place, we'll have to find a manual way of doing so (which should also be no big deal with So if you could set this up for |
Marking as stale due to 90 days with no activity. |
Marking as stale due to 90 days with no activity. |
@ctavan: I've recently set up
runmd
to use https://github.com/google-github-actions/release-please-action for release handling. 'Haven't done a whole lot with it, but I've got it working and have tested it out. It seems like a pretty decent solution to the problem of managing releases.tl;dr: Any commit to
main
that indicates patch/fix/breaking change (via conventional commit message) will trigger the creation of a PR that updates CHANGELOG.md and package.json#version. As new commits come in, the PR is updated to reflect the latest state of the release. To push a release, just merge the PR (which triggersnpm publish
in the workflow.)Seems like a pretty elegant solution. I'm happy to put up a PR, but 'figured I'd float the idea here first, in case I'm overlooking something obvious.
The text was updated successfully, but these errors were encountered: