Our hash-based versioning confuses sbt eviction

Motivating example:

[error] 	* edu.gemini:lucuma-ui_sjs1_2.13:0.24.0-27-cc6bf86-SNAPSHOT (early-semver) is selected over 0.24.0
[error] 	   +- edu.gemini:explore_sjs1_2.13:20220208--UNCOMMITED  (depends on 0.24.0-27-cc6bf86-SNAPSHOT)
[error] 	   +- edu.gemini:common_sjs1_2.13:20220208--UNCOMMITED   (depends on 0.24.0-27-cc6bf86-SNAPSHOT)
[error] 	   +- edu.gemini:react-aladin_sjs1_2.13:0.12.1           (depends on 0.24.0)

Selecting 0.24.0-27-cc6bf86-SNAPSHOT over 0.24.0 is good.

However, not recognizing that 0.24.0-27-cc6bf86-SNAPSHOT must be bincompatible with 0.24.0 is not-so-good.

I believe the relevant code in sbt is here:
https://github.com/sbt/librarymanagement/blob/67988135152f88afa9134fcfc357c0901e700f40/core/src/main/scala/sbt/librarymanagement/VersionNumber.scala#L198

Specifically:

     * Rule 9:
     * > A pre-release version MAY be denoted by appending a hyphen and a series of
     * > dot separated identifiers immediately following the patch version.
     * > Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-].
     * > Identifiers MUST NOT be empty.
     * > Numeric identifiers MUST NOT include leading zeroes.
     * > Pre-release versions have a lower precedence than the associated normal version.
     * > 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.
     * > Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

What I don't understand is why 0.24.0-27-cc6bf86-SNAPSHOT is selected over 0.24.0 (although this is in fact what we want) given that "Pre-release versions have a lower precedence than the associated normal version."

This part is tricky:

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.

While it is true that you can't use a pre-release to establish compatibility guarantees, you can still trust that it is compatible with previous releases in its series.

Also note that this could be general conflicts with semver, not specific to sbt. See:

• https://github.com/semver/semver/issues/394
• https://github.com/semver/semver/issues/200

I'm sure there are other subtleties and implementation details at play.

Politely pinging @eed3si9n, would appreciate any insight you have here.

Start with the linked sbt/librarymanagement VersionNumber.scala location and compare its version-selection behavior with the motivating eviction output. Read the referenced SemVer issues to understand the compatibility question. Done means establishing whether this is an sbt bug or a SemVer limitation and defining a concrete compatibility behavior.