Closed decanTyme closed 1 year ago
One actual solution to all this mess is to just use ~standard-version
~ release-please
for all versions <1.0.0
, then migrate back to semantic-release
once ready to move to 1.0.0
. But that means some things must be done manually.
After some testing out release-please
, its workflow finally makes sense. Suffice to say it is a godsend. It works like magic and can be configured with just these two:
bump-minor-pre-major: true
bump-patch-for-minor-pre-major: true
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 semantic-release
, especially if there are multiple release branches and pre-release branches (!).
There's also some limitation with using the default GITHUB_TOKEN
secret ~that might be worth looking into~. Doesn't seem to work with it and you get an error (also seems to loop-retry forever), only a Personal Access Token works:
✔ Starting GitHub PR workflow...
✔ Successfully found branch HEAD sha "cdd6bb10593479d3d1694b13ed80a1c7234a22e1".
✖ Error when creating branch
✖ RequestError [HttpError]: Error creating Pull Request: Resource not accessible by integration
✔ Retry attempt #1...
at /home/runner/work/_actions/google-github-actions/release-please-action/v3/dist/index.js:16560:21
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async createBranch (/home/runner/work/_actions/google-github-actions/release-please-action/v3/dist/index.js:22042:26)
at async branch (/home/runner/work/_actions/google-github-actions/release-please-action/v3/dist/index.js:22070:9)
at async retry.retries (/home/runner/work/_actions/google-github-actions/release-please-action/v3/dist/index.js:22815:48)
at async createPullRequest (/home/runner/work/_actions/google-github-actions/release-please-action/v3/dist/index.js:22815:24)
at async /home/runner/work/_actions/google-github-actions/release-please-action/v3/dist/index.js:85509:30
at async GitHub.createPullRequest (/home/runner/work/_actions/google-github-actions/release-please-action/v3/dist/index.js:86585:20)
at async Manifest.createOrUpdatePullRequest (/home/runner/work/_actions/google-github-actions/release-please-action/v3/dist/index.js:87114:32)
at async Promise.all (index 0) {
status: 403,
response: {
...
data: {
message: 'Resource not accessible by integration',
documentation_url: 'https://docs.github.com/rest/reference/git#create-a-reference'
}
},
...
}
...
✔ Retry attempt #2...
...
Note that fine-grained PATs don't work with GitHub's GraphQL API just yet.
One caveat Two caveats are 1) it doesn't support signing commits, at least not yet but the foundation is there (https://github.com/googleapis/code-suggester/pull/442) and they're just waiting for an implementation from someone, I guess; and 2) prerelease branches are still pretty much in a "to be designed", RFC state (https://github.com/googleapis/release-please/issues/510#issuecomment-1020248692).
Alright, I've tested out much of release-please
(excluding monorepo things). Will have to rebase most things now as I wanna get rid of existing tags and stuff from semantic-release
. Hopefully, signing commits will be fully supported in the coming months (although it seems that the tags themselves are signed with GitHub’s verified signature).
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).