add default versionScheme

[Sciss]

It seems that modules should all follow the <major>.<minor>.<patch> scheme, instead of the <epoch>.<major>.<minor> scheme used by normal Scala libraries. sbt when using evicted looks at the version scheme information of the library's pom, defaulting to <epoch>.<major>.<minor> when absent. Thus, we get evication warnings, for example, when scala-xml 1.2.0 and 1.3.0 are mixed, although it would be binary compatible?

Therefore, I suggest to inject a default versionScheme to scala modules. This is supported since sbt 1.4. See also: sbt/sbt#5724

As far as I see, the three allowed values are "early-semver", "pvp", and "semver-spec", and the default would be "pvp". sbt has no information what these mean, but https://github.com/scalacenter/sbt-eviction-rules gives some clues:

• early-semver: assumes the matched modules follow a variant of Semantic Versioning that enforces compatibility within 0.1.z.
• semver-spec: assumes the matched modules follow Semantic Versioning Spec that assumes no compatibility within 0.1.z.
• pvp: assumes the matched modules follow package versioning policy (quite common in Scala),

That would mean we should use always ? It's quite confusing, I don't see how compatibility witihin 0.x.y. is assumed. Perhaps we're doing it wrong for modules altogether and should use pvp instead?

[Sciss]

Clarification: "early-semver" and "semver-spec" only refer to versions that begin with zero, like 0.1.2. I think the scheme used here is therefore "semver-spec".

[eed3si9n]

There's some documentation in https://www.scala-sbt.org/1.x/docs/Publishing.html#Version+scheme as well. Generally I'd recommend using "early-semver". This lets you keep bincompat between the patch version, but forces stabilization post 1.0, which I think strikes a good balance.

[SethTisue]

@Sciss I've dragged my feet about responding to this because I'm somewhat reluctant to pile more stuff into sbt-scala-module unless it provides more value than just setting a setting that individual module maintainers could easily set themselves. the more settings come from sbt-scala-module, the more the individual module builds become mysterious things where you don't quite know what sbt-scala-module is or isn't giving you, unless you study it.

and for versionScheme in particular, in order to set it here in this repo, we'd need to audit every module and make sure that the default was appropriate, I think the real goal here is for most or hopefully all of the modules to set versionScheme appropriately, but I'm not confident without actually doing that audit that all the modules would agree. and if we don't do that audit, then Scala Steward will bump all the repos to the latest sbt-scala-module and individual maintainers might merge those upgrade PRs without thinking

another path towards the goal could be to open a ticket in every module requesting that the maintainer there set their versionScheme appropriately

should we actually enforce that all the modules follow the same scheme? again, I find it hard to have an opinion about that without auditing all the modules first to see where things stand, so we'd know how big a change it would be

any other opinions on this...? @scala/maintainers

note that I've expanded the @scala/maintainers membership to include even Lightbend and Scala Center folks who are the lead or co-lead maintainers of at least one repo, so we can @-mention the team and know we're reaching everyone with a personal stake in questions like these

oh and cc @NthPortal who I just added to that team as well (since you seem to be be assuming de facto co-leadership over in scala-library-next)

[julienrf]

Hey, thanks for pinging me :)

First, I’m really happy to see this discussion happening! Second, I’m very sorry for not having taken more time to document and advertise the use of versionScheme.

I believe this setting is very important, and that all the libraries should be using it. As Eugene said, the recommended versioning scheme is "early-semver", so it would be good to use this scheme for the Scala modules as well.

[Sciss]

Regarding @SethTisue 's concern; I don't see a problem, adding it individually to the module projects (e.g. scala-xml – which shows up mostly in my evicted warnings – swing etc.)

[NthPortal]

I definitely think all modules ought to be on "early-semver"; I don't have strong feelings about how we get there

[SethTisue]

re: my concern about modules inadvertently getting a wrong default, I suppose I could add the default to the plugin, publish, wait for the Scala Steward PRs to roll in, and then comment on each one, "don't merge this without checking that the new setting it appropriate"... that kind of thing

[eed3si9n]

Here are the repos currently using sbt-scala-module according to https://github.com/search?l=&o=desc&p=1&q=sbt-scala-module+extension%3Asbt&s=indexed&type=Code

repo	latest	is it early-semver?
scala/scala-collection-compat	2.3.1	???
scala/scala-swing	3.0.0	maybe, if you can keep it
scala/scala-collection-contrib	0.2.2	maybe, if you can keep it
scala/scala-async	1.0.0-M1	maybe, if you can keep it
scala/scala-xml	2.0.0-M3	maybe, if you can keep it
scala/scala-parallel-collections	1.0.0	maybe, if you can keep it
scala/scala-parser-combinators	1.1.2	no
scala/scala-library-next	0.0.1	maybe, if you can keep it
scala/scala-java8-compat	0.9.1	maybe, if you can keep it
lrytz/travis-test	0.3.0-RC1	maybe, if you can keep it
scala/scala-continuations	1.0.3	discontinued
scala/scala-partest	1.1.9	discontinued

• nsm-lab/scala-partest
• nsm-lab/scala-xml
• nsm-lab/scala-swing
• nsm-lab/scala-java8-compat
• exoego/issue-scala-module-crosstype-pure
• yurelle/ScalaMatrixLibrary

[julienrf]

@SethTisue I understand your concern, and I agree that setting the versionScheme here is probably not the best idea, unless we add a mechanism that checks that the release actually conform to that versioning scheme (like we have in https://github.com/scalacenter/sbt-version-policy).

Maybe it’s simpler to start with setting it manually in a couple of modules? A good candidate is scala-collection-compat, which is always in your classpath nowadays, and causes false warnings like this one:

[warn] Found version conflict(s) in library dependencies; some are suspected to be binary incompatible:
[warn]  * org.scala-lang.modules:scala-collection-compat_2.13:2.1.6 is selected over {2.1.4, 2.0.0}
[warn]      +- org.endpoints4s:algebra-json-schema_2.13:1.1.0     (depends on 2.1.6)
[warn]      +- io.scalaland:chimney_2.13:0.5.3                    (depends on 2.1.6)
[warn]      +- com.typesafe.slick:slick_2.13:3.3.2                (depends on 2.0.0)
[warn]      +- com.lihaoyi:upickle-core_2.13:1.1.0                (depends on 2.1.4)

[SethTisue]

now that https://www.scala-lang.org/blog/2021/02/16/preventing-version-conflicts-with-versionscheme.html has been published, we should reallllly make sure the modules declare a policy (whether it's through the plugin, or independently). I won't have time this week, but I should have time next week

[SethTisue]

rather than address this in this plugin, I've opened tickets in the individual module repos.

I'll tackle these myself:

• Build should declare a versionScheme scala-parallel-collections#163
• Build should declare a versionScheme scala-collection-compat#434
• Build should declare a versionScheme scala-java8-compat#210
• Build should declare a versionScheme scala-xml#497

and I leave these for volunteers:

• Build should declare a versionScheme scala-swing#150
• Build should declare a versionScheme scala-parser-combinators#360
• Build should declare a versionScheme scala-async#259
• Build should declare a versionScheme scala-collection-contrib#129
• Build should declare a versionScheme scala-library-next#72

[SethTisue]

I've now done those four repos.