Feature Request: allow to specify semver leven of an rc

[Licenser]

What am I trying to achieve?

As part of deployment, I want to create a release candidate that is not necessarily a patch release, for example, going from 1.2.3 to 1.3.0-rc.1

What happens right now (observed behavior)

When running --bump rc it always is a patch release, so 1.2.3 becomes 1.2.4-rc.1 when releasing then one needs to choose to release it as major, minor or patch as the plain release that just removes the rc will only go to patch.

Alternatives (that do not properly work):

• Using set-version --bump minor followed by --bump rc will create a 1.3.1-rc.1
• Using set-version --bump minor followed by a set version 1.3.0-rc.1 fails since downgrading a version is not allowed

Why is this a problem

There is no way to move a release from 1.2.3 to 1.3.0 with one or more rcs in the process, one either ends with 1.3.1 as a new version, or has release candidates for 1.2.4-rc.* which would be incorrect in sem-ver terms if changes require a minor release.

Expected behaviour

A way to increase a RC for both minor and major versions as well so that one can move a release from 1.2.3 to 1.3.0-rc.1 ... 1.3.0-rc.N to 1.3.0 giving each release the expected and correct semver version.

Sugested change

Add minor-rc and major-rc (or alternative namings) to the options for --bump; or alternatives I've not thought about

Work

I'm happy to prepare a PR for the changes if a desired change is agreed on

[epage]

Yes, this has been a shortcoming in cargo release from which this command was split out from. The current workaround is to do cargo set-version 1.3.0-rc.1.

In considering this in cargo release, I've not been too thrilled with the options I've seen and have just left it to the workaround for now. For example, I'm not thrilled with the explosion of options for <release-level>-<pre-release-level>. Maybe it could be comma separated so you can do multiple bumps, like minor,rv? I feel like there is a clarity problem there.

So while I don't feel decisive on an answer to say this should move forward with a PR to close this out, I do want to leave this open for further exploration of this problem and potential solutions. That can include this conversation leading me to change my mind about one of the above ideas.

[Licenser]

Understandable, the problem with cargo set-version 1.3.0-rc.1 is that to do it in an automatic way, it requires re-implementing the entire logic for bumps outside of set-version again which feels terribly wasteful.

I'll throw in a few ideas:

• , as you suggested
• + so it would become minor+rv which to me reads nicerer then ,
• a extra flag per 'pre release', basically removing the modifiers in bump and using --rc or --alpha instead, so it naturally composes cargo set-version --bump minor --rc (bump the minor and increase the RC) or cargo set-version --rc (increase the rc) equivalent to current cargo set-version --bump rc`
• add a pre release argument a bit like the prior but makes it just one argument cargo set-version --bump minor --pre-release rc or cargo set-version --pre-release rc

( flag names just ideas not must-be-like-this namings ;) )

EDIT:

I like the extra flag(s) versions as they allow us to keep the existing command untouched (even so, eventually, rc, alpha, etc. could be removed) and not clutter up the existing value space and are completely opt in with no effect on existing users.