Support for pre-release

[jcornaz]

Is your feature request related to a problem? Please describe.

I would like to cut a pre-release

Describe the solution you'd like

Have a (documented) way to configure release-please so that it knows that I am publishing a pre-release.

It could be as simple as an argument of the CLI (example: --prerelease=alpha) and/or it could be via configuration file to map branch name with release type.

Describe alternatives you've considered

Well, except using another tool than release-please, I don't see how to achieve that.

Additional context

I'm not sure what to add here. The context is releasing a software early as a pre-release...

[simenandre]

I'd love to help out with this!

[parthea]

It appears that release please only supports the alpha suffix for pre-releases, although I haven't tried it. https://github.com/googleapis/release-please/blob/master/src/release-pr.ts#L308 . For python, I'd like to use these suffixes devN, aN, bN, and rcN. See
https://packaging.python.org/guides/distributing-packages-using-setuptools/#pre-release-versioning

[chingor13]

v13 now supports more robust version handling (prerelease and build numbering). If we build something for this, we need to design how we signal to release please that we need to bump to a prerelease candidate versus a stable release. The CLI could accomplish this via a CLI option, but the GitHub action and app would not be able decide whether or not to use that flag.

[jcornaz]

v13 now supports more robust version handling (prerelease and build numbering). If we build something for this, we need to design how we signal to release please that we need to bump to a prerelease candidate versus a stable release. The CLI could accomplish this via a CLI option, but the GitHub action and app would not be able decide whether or not to use that flag.

The github action is configurable: https://github.com/marketplace/actions/release-please-action#configuration

Example:

      - uses: GoogleCloudPlatform/release-please-action@v2
        with:
          pre-release: beta

For the gihub app I don't know. But many github apps are configurable via a configuration file in the .github directory.

EDIT: Yep, indeed the github app is configurable via the .github/release-please.yml file.

Eventually, the configuration may be a map of branch-name to prerelease-label. So one can have a main branch for stable releases and a beta branch for betas.

[jcornaz]

Hi, May I kindly ask where are we with this issue? May I help somehow? Are there still open questions that need to be solved first?

[bcoe]

@jcornaz @cobraz @chingor13 my suggestion is to submit a rfcs/pre-release.md as a PR, which provides a proposed design for how we should handle pre-releases, we can move the discussion there.

Once we get a design in writing we like, then we can work on implementation. I'd love to start moving release-please towards this RFC approach, so that our design is intentional.

[erezrokah]

Thanks @bcoe, I have a suggestion that could improve the current state a bit (happy to write an RFC for it if you think it makes sense).
GoReleaser has a prerelease: auto configuration, which means that if it detects a tag that matches a pre-release (e.g. v0.0.4-rc2) it will set the GitHub release to prerelease automatically.

Then one could git commit --allow-empty -m "chore: release 0.0.4-rc2" -m "Release-As: 0.0.4-rc2" to cut a pre-release.

The pre-release detection could be configured via the GitHub action (defaults to false), and also reported via the action outputs.

I'd be happy to contribute this change as well (pending rfc and feedback).

Update

Looks like the code does something similar already

release-please/src/manifest.ts

Line 960 in a682275

(!!release.tag.version.preRelease ||

by passing the --prerelease flag, however it also looks at major === 0 to mark GitHub releases as pre-releases

Another update

I was able to find a solution for my use case, see https://github.com/cloudquery/cq-provider-releaseplayground/blob/8857679339b2cc5f9b784e98e027f2899760f589/.github/workflows/release-pr.yml#L28

[ooliver1]

I personally would be greatful for even just being able to input if I want it to be a prerelease to the action and I can use the branch name in the workflow syntax, I can do that for draft releases

Edit: another issue is that the action errors when it cannot find a normal release and only finds a prerelease release

[IgnacioNMiranda]

Hi everyone :) I'm trying to set a release as a pre-release but it's not working at all with the existing prerelease flag we can use in github actions.

Is this a bug? Is it already reported? Am I doing anything wrong?

BTW - Also expecting to be able to create releases as v1.0.0-alpha or something like that, I think it's reaaaally needed.

Thanks (:

[eversardoth]

Hello,

Is there any roadmap for this feature being implemented in the near future? @chingor13

Would really appreciate an answer :).

[alexgwolff]

updates?

[broofa]

@jcornaz @cobraz @chingor13 my suggestion is to submit a rfcs/pre-release.md as a PR, which provides a proposed design for how we should handle pre-releases, we can move the discussion there.

Late to the party, but I went ahead and created said PR, as I've run into this issue in my attempts to move uuid onto release-please-action for our release process.

Edit: I would encourage people interested in this issue to read and comment here: #2051

[kalosisz]

by passing the --prerelease flag, however it also looks at major === 0 to mark GitHub releases as pre-releases

Hey @erezrokah, it also look if the preRelease group in this regex pattern

release-please/src/version.ts

Lines 17 to 19 in 2e28edf

	const VERSION_REGEX =
	/(?<major>\d+)\.(?<minor>\d+)\.(?<patch>\d+)(-(?<preRelease>[^+]+))?(\+(?<build>.*))?/;

is present.

[chingor13]

We are definitely open to adding additional versioning strategies.

Additional considerations:

• which commit types influence each version bump
• how (or if) the primary semver numbers will change
• how (or if) the release becomes non-prerelease

Additional note: we added a prerelease versioning strategy that follows our googleapis/google-cloud-dotnet libraries handle pre-release versioning in #1981. If that one does not suit your needs, it could be used as a blueprint for a similar new versioning strategy.

[matthewhartstonge]

@chingor13 the issue I'm seeing here is that the current implementation is not Semantic Versioning compliant based on https://semver.org/#spec-item-9

The RFC that @broofa has written up aligns with the spec - which is neat :)

My 3 questions are:

• Do we want to bring the current implementation into specification alignment for community betterment?
• Do we want to proceed down a fragmented line of creating a new prerelease-semver strategy that is spec-compliant?
• Do both - by setting the spec compliant strategy as default prerelease, with the current implementation migrating to something like prerelease-noncompliant

[danieleades]

Additional considerations:

...

• how (or if) the primary semver numbers will change

the primary version numbers should change the same way they do currently. if there is a breaking change the major version should increment even if it's a pre-release. The pre-release suffix indicates the stability of the release and the primary semver numbers capture the API compatibility. These are orthogonal (separable).

• how (or if) the release becomes non-prerelease

this is harder. I would suggest creating two PRs:

1. one PR increments the pre-release number
   • keep the same pre-release suffix and increase the number, unless-
   • if the semver compatibility changes, increase the corresponding number and reset the pre-release suffix number
   • each prerelease has a separate header in the changelog
2. a second PR increments the pre-release type
   • "alpha" -> "beta", "beta" -> "rc", "rc" -> "" (stable)
   • when increasing the pre-release type, collapse the pre-release headers since the last stable release into a single header (such that pre-release headers are transient and not kept after a more stable version of the same release is produced)

as a user, you then decide which of the two PRs to merge to either 'stabilise' the release, or simply increment the pre-release number