feature(prerelease-type): changing prerelease-type in manifest or from cli does not bump to new status and reset counter.

[jasonbraley]

Problem description:
My product goes through an alpha, beta, rc, release cycle. Fairly standard. I cannot seem to find a way through the config/manifest system to move to the next phase of prerelease. prerelease-type in the manifest seems to just be ignored if the previous prerelease status was not empty

Solution:
When doing a prerelease version bump, the code should check the prerelease-type flag and if it doesn't match the last version, use this new value and reset the counter to zero.

Alternatives:
I've currently been using release-as: to move to the next phase. It works, but it's not automated.

[wraithgar]

@chingor13 I see this is assigned to you. We (npm) are using release-please and also have found several issues w/ how release-please approaches pre-releases. The TLDR is that it's not really following the semver spec, nor is it even using the semver package to affect semver versioning. This leads to the issue describe here, as well as other issues such as not actually being able to leave pre-release mode once you are in it.

We ended up having to use our own fork with a custom versioning stragtegy in the past. We're no longer using that fork, but are likely going to have to re-implement that custom strategy in our release-please consumer to ship npm 11 this week.

It'd be great if long-term we could go back to using a versioning strategy that ships with release-please. I would love to help here if possible.

[wraithgar]

Using semver itself in the default and prerelease version strategies, with the same bit of logic from the custom strategy I linked above, would fix this bug and the one we're having with being unable to leave pre-release mode.

> semver.inc('1.1.1', 'premajor', 'pre')
'2.0.0-pre.0'
> semver.inc('2.0.0-pre.0', 'prerelease')
'2.0.0-pre.1'
> semver.inc('2.0.0-pre.0', 'major')
'2.0.0'
> semver.inc('2.0.0-pre.0', 'prerelease', 'foo')
'2.0.0-foo.0'

[reggi]

I created a pr with some context regarding the current issues and troubles we've had #2451

[reggi]

@jasonbraley to unblock you theoretically you could set "versioning": "prerelease" (undocumented property 😠 ) with the "prereleaseType": "alpha" and it may work, not 100% though. Also once you're in prerelaese it may not leave 😆

[jasonbraley]

Tried that. No dice. Once a pre-release tag has been created in the git history, that seems to be the only information it uses in determining the next increment. Changing the prerelease-type had no effect.

…

On Wed, Dec 11, 2024, 5:12 PM Reggi ***@***.***> wrote: @jasonbraley <https://github.com/jasonbraley> to unblock you theoretically you could set "versioning": "prerelease" (undocumented property 😠 ) with the "prereleaseType": "alpha" and it may work, not 100% though. — Reply to this email directly, view it on GitHub <#2447 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5AWPBOGBLPYNHQUNCZ23T2FC2EFAVCNFSM6AAAAABS6XPRWKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZXGMYDKMZRGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>