Prerelease is included into the update proposal

[eed3si9n]

steps

scala/scala-collection-compat#254

problem

sbt-pgp 2.0.1-M3 is a prerelease version.

expectation

Prerelease versions should not proposed.

notes

#665 added sbt plugin proposal. I don't see anything about dependencyAllowPreRelease there, so I'm not sure where it's coming from.

[fthomas]

Thanks for the report, @eed3si9n! I think this happened because sbt-updates considers 1.1.2-1 a prerelease (because of the -1) and therefore also lists 2.0.1-M3 as an acceptable newer version. Projects that use(d) sbt-pgp 1.1.2 received updates to 2.0.0 only.

[eed3si9n]

Based on Semantic Versioning, I think it's fine to consider 1.1.2-1 a prerelease (even though there have been prior cases like Scala 2.9.1-1).

To simplify the discussion, let's suppose it was called sbt-pgp 1.1.2-M1 instead and suppose that was a legitimate milestone for sbt-pgp 1.1.2. Even still, I don't think the fact that the project used one prerelease should be considered a signal that it's at all safe to bump to a prerelease of sbt-pgp 2.0.1 or any other future versions.

According to https://semver.org/spec/v2.0.0.html#spec-item-9:

A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.

This is the case with sbt at least where we might be adding new API and removing APIs as we learn things, and I'd assume for most libraries too. If someone by accident merged a non-bincompat upstream library, they could end up producing a non-bincompat libraries themselves.

[fthomas]

I agree with you that updating to a prerelease of a different version doesn't make much sense. There was another PR where ScalaTest was updated from 3.1.0-SNAP13 to 3.2.0-M1 but waiting for 3.1.0 final would have been the more sensible option here.

Btw, I think updates to a newer prerelease of the same version are fine, for example from 1.1.2-M1 to 1.1.2-M2.