In maven ordering, a shorthand milestone identifier ("m") must be followed by a number to be considered as such, else the segment is not special. See https://github.com/apache/maven/blob/master/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L176 (only spec I know of for maven version rules).
So it means that cats-core_2.12-1.0.0 is considered to be before cats-core_2.12-1.0.0-MF, which is not good at all: nobody will ever be able to use [1.0.0,1.1) (or any qualifier meaning '1.0 or above, binary compatible version).
See for example in maven central:
Artifacts being published (and can't be unpublished in an open world), that horse left a long time ago, so I'm not sure what is the correct way forward.
Perhaps the best option is to have a 1.0.1 release quickly, which would assure that the versionning of the whole ecosystem is correct regarding the 1.0 branch, which aims to be stable.
In maven ordering, a shorthand milestone identifier ("m") must be followed by a number to be considered as such, else the segment is not special. See https://github.com/apache/maven/blob/master/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java#L176 (only spec I know of for maven version rules).
So it means that
cats-core_2.12-1.0.0is considered to be beforecats-core_2.12-1.0.0-MF, which is not good at all: nobody will ever be able to use[1.0.0,1.1)(or any qualifier meaning '1.0 or above, binary compatible version).See for example in maven central:
1.0.0-MFis not red1.0.0-MF.Artifacts being published (and can't be unpublished in an open world), that horse left a long time ago, so I'm not sure what is the correct way forward.
Perhaps the best option is to have a
1.0.1release quickly, which would assure that the versionning of the whole ecosystem is correct regarding the1.0branch, which aims to be stable.