-
Notifications
You must be signed in to change notification settings - Fork 0
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
Release Automation #10
Comments
One actual solution to all this mess is to just use |
After some testing out
While it's not a complete automation (i.e. you still have to manually merge auto-PRs, which in some cases is a good thing), I imagine it might work in this case. It just makes consolidating together changes to a single release so much easier. Requires a little more configuration than There's also some limitation with using the default
Note that fine-grained PATs don't work with GitHub's GraphQL API just yet.
|
Alright, I've tested out much of |
As explained here, I'm looking to re-release as 0.x and therefore looking at some alternatives to semantic-release. Will update this as more testing is done.
0.y.z
handling, though it seems tied to GH Actions and I still don't know if its "automation" workflow makes sense for this (I want to able to just push, merge changes and have it uploaded directly to npm without worrying about anything else). This is by far the best bet on this list.0.y.z
handling but upon testing it out, it doesn't seem to be that way (i.e. it bumps to1.0.0
when breaking changes are found; using the @release-it/conventional-changelog plugin andconventionalcommits
preset). Seems nice though for manual version releases, as it prompts on what version should be released (non-CI). Can be configured for CI with shareable plugins.0.y.z
handling but is now deprecated, so it's not high on the list anymore. There is a promising fork though.To be honest, I'd like to continue using
semantic-release
as it is really a streamlined workflow. Really, the only problems with it right now is how it's handling0.y.z
version bumps and their unyielding opinions on starting with1.0.0
. Other than that, if I don't find a good substitute for it in the end, I'd still be happy to use it moving forward.TL;DR (for closing #8):
[Semantic] Versioning (as it is right now) on major version < 1 is a hellhole of a mess, but is currently leaning towards
0.y.z
wherey
CAN have breaking changes, intentional or not; and wherez
can be any other change (additives, bugfixes, etc).The text was updated successfully, but these errors were encountered: