feat: adds "semver" versioning-strategy #2451
Draft
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.
First off 🫶 thank you for woking on release-please it makes our lives much easier.
I work on the
npm
cli which usesrelease-please
. I think its safe to say we're power users and rely on theprerelease
functionality.This PR adds a proper "semver" strategy. There's a lot of issues related to
prereleases
when it comes to the existingPrereleaseVersioningStrategy
andDefaultVersioningStrategy
(more below), these can be fixed but I think still will not do "proper" / "intended" semver incrementation.There are also issues with semver itself which we aim to fix in https://www.npmjs.com/package/semver in a future release, this pr shims that functionality for now with a custom
semver.inc
impementation.I'll copy some of my findings from npm/template-oss#495 but keep in mind the context:
reggi/packages
.npm/cli
has been stuck in prerelease mode. It was able to get itself into prerelease because of the wrapper around release-please we have in this repo. (trail: npm/cli workflow, Strategy Turnery)I do not believe release please has this
options.prerelease ternary anymore
here's the mapping of what versioning-strategy is uses.And even if it did choose to use
PrereleaseVersioningStrategy
orDefaultVersioningStrategy
neither of these strategies have the ability to leave a prerelease. Because they always add the currentprereleaseType
orprereleaseType
from the config from the existing version. Neither of these classes even have access to theoptions.prerelease
boolean. And at the point in which both have it whats the point in differentiating between them anymore?This is added as a new versioning-strategy
semver
. To note the property currently documented asversioning-strategy
in the docs is not working, and is currentlyversioning
. I opened a PR to fix the json schema for the config, but now we know it's a bug i'll leave that discussion open there.So
"versioning-strategy": "semver"
would be ignored and you'd need"versioning": "semver"
, again not relevant to this PR but another quirk to note.I'm going to keep this in draft for now, just want to open up for discussion, and next steps. My main questions are
release-please
team open to new "semver" versioning strategy?PrereleaseVersioningStrategy
orDefaultVersioningStrategy
and just useSemverVersioningStrategy
?I also have a published fork if anyone wants to try it https://www.npmjs.com/package/@reggi/release-please