Support version scheme in pom

[lolgab]

Sbt recently added the possibility to state the versioning scheme in poms to allow precise binary compatibility checks.
https://scala-lang.org/blog/2021/02/16/preventing-version-conflicts-with-versionscheme.html

This PR implements some basic support to add the versionScheme to PublishModules.

All the naming and packages are arbitrary.
Suggestions accepted :) (as usual)

cc. @julienrf

[julienrf]

That was quick, thank you!

[lefou]

Thanks for this contribution. Can you tell, if coursier actually supports this info.versionScheme property, so that we also can benefit from it, or is this only used by sbt to filter coursier version resolutions by impact?

This PR effectively adds some property to the pom.xml, so I think the better implementation would be to add generic property support to mill.scalallib.publish.Pom, and then just derive the correct property from the selected version scheme. Also adding a properties or pomProperties setting to PublishModule would be nice, but can also be done later in a separate PR. I don't know, if the ivy file also support properties, but if, we should add the versionScheme property there too.

[julienrf]

Thanks for this contribution. Can you tell, if coursier actually supports this info.versionScheme property, so that we also can benefit from it, or is this only used by sbt to filter coursier version resolutions by impact?

As far as I know, the logic is implemented in sbt/librarymanagement: https://github.com/sbt/librarymanagement/blob/develop/core/src/main/scala/sbt/librarymanagement/EvictionError.scala

Here is Coursier documentation about versions handling: https://get-coursier.io/docs/other-version-handling

I believe it would make sense to move that logic upstream to coursier. Maybe @alexarchambault or @eed3si9n have an opinion?

I think the better implementation would be to add generic property support to mill.scalallib.publish.Pom

I agree. properties are also used to indicate the URL of the API documentation (via the info.apiURL element), which can be used by some tools. There are maybe other usages.

[lefou]

@julienrf Thanks for the pointers. I think properties are in general useful for interoperability with downstream consumers.

[lefou]

This PR needs to be rebased on latest main branch. The versionScheme target should then feed the publishProperties. The default scheme should be None so that (if nothing is configured) publishing works as previously and no extra property will be added. Some Scaladoc on publishProperties should denote, that some logic is already present and calling super is required to keep it.

[lolgab]

Rebased the PR and applied the suggested change.
Do think it's better to exposed the Option with versionScheme being a Option[VersionScheme] or a VersionScheme as it was before where NoScheme was a special scheme containing None as value?

Defining a versionScheme in the previous way way was slightly nicer:

override def versionScheme = VersionScheme.EarlySemver

Instead of:

override def versionScheme = Some(VersionScheme.EarlySemver)

I took the idea from ScalaJSModule that defines the ModuleKind as NoModule.
It was my first contribution to Mill in 2018 :) #212

Anyway, @lefou let me know which one you prefer.

[lefou]

Do think it's better to exposed the Option with versionScheme being a Option[VersionScheme] or a VersionScheme as it was before where NoScheme was a special scheme containing None as value?

I think the use of an Option[VersionScheme] better transports the fact that no version scheme needs to be applied at all and also no property will be created from it when absent. With a VersionScheme.NoScheme this may be less obvious. A None can be understood without looking at VersionScheme and without studying all the provided cases.

[lefou]

LGTM. Thank you very much!