Convert a prerelease version to stable version

[b0lle]

Is your feature request related to a problem? Please describe.
I need to create development versions which indicates that the package version is under development and should be used with care.
So I came up with the "prerelease" version strategy which fits that need pretty nice.
When I finish the development I wanted to change the versioning strategy from "prerelease" to "default", which results in an unexpected behaviour:
v1.0.0-dev.4 (created by 5 runs of "prerelease" version strategy, one commit was "feat!") were bumped to
v2.0.0-dev.4 ("default" version strategy)

What i expected though is the new version v1.0.0

Describe the solution you'd like
The idea I came up with is a new versioning strategy. Lets call it "release-from-prerelease" and its very simple:
While the "prerelease" already handles version bumps very well, the new strategy only needs to get rid of the "build" and "prerelease" property. As a result we can use the "CustomVersionUpdate" updater like this:

    return new CustomVersionUpdate(
      Version.parse(`${version.major}.${version.minor}.${version.patch}`).toString()
    );

Describe alternatives you've considered
A more clean way would be the implement that behaviour in the "prerelease" property - So when the "prerelease" prroperty was set, then use the "prerelease" versioning strategy, otherwise set the new "release-from-prerelease" startegy.
Another way would be to change the "Major/Minor/PatchVersionUpdate" classes, but I think that might have some side-effect

Additional context
I know there are discussions how to handle pre-releases well here, but they are ongoing for four years. I can not understand how release-please took so much hype without pre-release handling. Hope this issue makes a little step to takle this, even if its very simple.

[b0lle]

I made this work by correcting the "prerelease" strategy, see #2516.
There I combined the versioning strategy with the config property "prerelease". In my head this fixes the strategy by being able to dynamically switch between a prerelease version and a non-prerelease version.

Unfortunately the gh-action does not provide the "prerelease" config property yet, but that would be easy to add

[JonasCir]

I was able to create a "correct" release after a couple of per-releases by switching the strategy back from prerelease to default and manually resetting the version in the manifest file (e.,g., {"some_package": "0.3.0-rc2} back to {"some_package": "0.2.0}. After this change was picked up by release-please, I had my release PR for 0.3.0.

But I agree, this is not very intuitive and above all not documented. There should be a dedicated section in the docs on how to do pre-releases.

---

Edit:
I only use the config and do not pass any arguments to the action besides the token.

[Aaron-Ritter]

@b0lle Is this what you are looking for https://github.com/sonderformat-llc/release-please-prerelease-example/ I wanted to always go through one or more rc (Release Candidates) before creating a release. @JonasCir what do you think about that approach?

[JonasCir]

Nice work @Aaron-Ritter! Using two manifests is a smart way of leveraging the behavior I described above.

It would be great if release-please would accept a prerelease-manifest.json as in your repo natively without needing multiple jobs with different arguments. With this approach, the tool just could look at the components in prerelease-manifest.json and happily create RC PRs and corresponding RC Releases once these PRs are merged. Eventually, the user creates a PR to empty the prerelease-manifest.json. Once merged, release-please creates the final release PR based on release-manifest.json.

[Aaron-Ritter]

In my example it fully takes care of that.

• Once an RC PR is merged, it will create a PR for a release.
• Which at that point you could merge, but if you make another commit in to the repo, the PR will be overwritten with a second RC PR.
• Once that is merged, another release PR is created.
• When you merge the release PR, the whole workflow starts again from the beginning.

Btw. the prerelease idea I got originally from https://github.com/3sidedcube/example-app I, extended it to run with branch protection rules and other improvements.

[clspeter]

@Aaron-Ritter Thank for the great example, it works for me.
But I have 1 question, can we keep the release PR after it open? For now It will be replace by new pre-release PR if I push a commit after release PR open.
My workflow is keep developing (commit) on main, but I would like to keep the last merged pre-release ready to release.
It would be nice separate pre-release and release PR. both release channel will only replace by it own.

[Aaron-Ritter]

@clspeter that requires some more complex logic, wouldn't know right now how to do that, sorry.

[b0lle]

Hey @Aaron-Ritter, thank you so much for your example!
Besides it would may fit my needs, I would love to have this PR merged anyhow because in my opinion the observed behaviour is unexpected and erroneous.
I kind of lost hope that this will ever gets merged, because the repo maintenance seems to be inactive until I see that @chingor13 recently merged a PR. I wonder if Chingor could please review this, or add more maintainers to this project #2545.