Let's get rid of the -pre suffix.

[fiveop]

As @nox stated in #363, no one else does it, and it apparently might cause, problems I don't fully understand, yet. Since, I don't see an advantage in having the pre in the repository all the time, I don't mind.

In addition, I would like to fix the next version to currently 0.(prev + 1).0 and not 0.prev.1, if we ever want to release a hotfix, we can do so in a separate branch with a 0.current.1 version.

I'll prepare an RFC, when I have time.

[posborne]

I agree that dropping the pre should be fine within the context of the Rust/Cargo. If user's are using a pre-release version they are pointing to git and Cargo.lock will be dealing with things appropriately.

[Susurrus]

I'd actually propose closing this and instead using cargo-publish to automate most of the process. It defaults to -pre for the next version, but I don't really think that's much of a problem. I use it for a couple of my crates and I expect it to garner widespread use among the Rust community and then it'll be less weird.

[nox]

@Susurrus Well that cargo-publish behaviour doesn't seem to be the one that most projects follow, so it may be a bad default on its part.

[nox]

Actually I'm confused… What do you mean by cargo-publish defaulting to -pre for the next version?

[Susurrus]

Sorry, I meant to indicate cargo-release as the tool that does this. And I believe you can configure the suffix, though I don't believe this is worth changing. There are no known risks of keeping -pre in the version name, as it's been like that for a long time now without issues.

We should clarify this in RELEASE_PROCEDURE.md, however before closing this.

[nox]

I wouldn't say "without issues", given there has been at least 2 issues about the release procedure being weird (#363 and this one), and again this is the only crate I know of which does that anyway.

[Susurrus]

I agree that we can remove this step so I filed #860.