Allow to select release increment after development

[ISibboI]

Usually at the time of publishing a version, it is not known what version will be published next, i.e. is it a major, minor or patch increment. In turn cargo-release seems to set the development version after a release to the next patch increment with an alpha suffix, which is good. For example, after releasing a major increment 3.0.0, the development version would be 3.0.1-alpha.0.

But then, there is no process to change from this alpha version to an alpha, beta or rc version of a higher tier.

Example:

• First I release 1.0.0, and cargo-release correctly sets the version to the smallest possible increment, that is 1.0.1-alpha.0.
• But then, I start implementing some API additions that qualify for a minor release, so I want to release 1.1.0. But I don't want to release it immediately, but first provide a release candidate, so that my clients can test if the new version would break things for them. So I want to release 1.1.0-rc.0. At the moment, this is not possible with cargo-release to the best of my knowledge.
• After releasing 1.1.0-rc.0 and maybe adding some patches, I want to release the actual 1.1.0. This is only possible with something I would call a hack, since it is not documented. I have to execute cargo release patch, which sounds like I would release a patch, but I actually release the finished 1.1.0.

For the first problem, that is selecting the right increment for the next release, I propose to allow cargo-release to be called with two levels, the first being major or minor, and the second one of rc, beta and alpha. The level patch is not required, since it is anyways incremented after a release. The effect of this would be the following. Say I am at 2.1.4-alpha.0, but my next release goal is 2.2.0. Assume, I first want to release an alpha of that goal. Then I would execute cargo release minor alpha to release 2.2.0-alpha.0. In my former example of releasing the release candidate directly, I would execute cargo release minor rc to go from an unreleased 1.0.1-alpha.0 to 1.1.0-rc.0. Do you see what I mean?

For the second problem, that is incrementing from a release candidate to the finished version, I propose to add a level final, that does nothing but removing the pre-release suffix from the version. For example, if I'm at 0.2.2-beta.1, then executing cargo release final would release 0.2.2 and increment the development version to 0.2.3-alpha.0.

[sunng87]

at the moment, you can

• cargo release alpha to bump version from alpha.0 to alpha.1
• cargo release beta to bump version from any alpha to beta
• cargo release rc to bump version from any alpha to rc directly

[epage]

In my former example of releasing the release candidate directly, I would execute cargo release minor rc to go from an unreleased 1.0.1-alpha.0 to 1.1.0-rc.0. Do you see what I mean?

Interesting. Seems like a reasonable need, just figuring out the right way to expose it.

For the second problem, that is incrementing from a release candidate to the finished version, I propose to add a level final, that does nothing but removing the pre-release suffix from the version. For example, if I'm at 0.2.2-beta.1, then executing cargo release final would release 0.2.2 and increment the development version to 0.2.3-alpha.0.

I believe we already do this implicitly when patch is specified. patch might be a misnomer for the behavior. My guess is its because this is the default?

            "patch" => {
                if !version.is_prerelease() {
                    version.increment_patch();
                } else {
                    version.pre.clear();
                }
                need_commit = true;
            }

[epage]

post-release bumps were removed and cargo release version was added. I think there is nothing more to do here.

If there is something I missed, let us know!