Consider yanking the rc.0 release for a different one

[thomaseizinger]

Technically, nothing is wrong with releasing a different pre-release version. Pre-releases are by definition unstable and can make breaking changes.

However, as we can see from mcginty/snow#146, getting this wrong is very easy and I am not sure how many people are aware of the subtleties in how pre-release identifiers are compared: Lexically.

This means the just released rc.0 has a higher precedence than the the previous pre.5 release and thus, cargo automatically upgrades to it.

I think the impact on the ecosystem would be less if breaking changes between pre-releases were to use a different pre-release identifier: alpha for example.

[tarcieri]

It's expected for rc.0 to to be lexicographically higher than pre.*. It's newer and signals a higher level of maturity.

But even if it were e.g. pre.6, what would that matter?

The problem is snow is requiring ^4.0.0-pre.2. This will match any new prerelease, even if they contain breaking changes.

Arguably this behavior is a bug in the semver crate. Prereleases are expected to contain breaking changes.

The solution is for snow to lock to =4.0.0-pre.2 until upgrading to newer prereleases (or ideally soon, releases)

[thomaseizinger]

Arguably this behavior is a bug in the semver crate. Prereleases are expected to contain breaking changes.

You are right. I just thought more about this and I came to the same conclusion. cargo likely shouldn't upgrade from one pre-release to the other (with the exception of alpha.1 to alpha.2 maybe?) But even that introduces a convention that people will have to learn.