Update sbt-version-policy to 2.0.0

[scala-steward]

Updates ch.epfl.scala:sbt-version-policy from 1.2.1 to 2.0.0.
GitHub Release Notes - Version Diff

I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.

If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.

Configure Scala Steward for your repository with a .scala-steward.conf file.

Have a fantastic day writing Scala!

Ignore future updates

Add this to your .scala-steward.conf file to ignore future updates of this dependency:

updates.ignore = [ { groupId = "ch.epfl.scala", artifactId = "sbt-version-policy" } ]

labels: sbt-plugin-update, semver-major

[julienrf]

Hold on, the build should fail unless we explicitly indicate that we want to bump the major version number. I will have a look next week.

Edit: actually that’s just because sbt-scala-module does not use sbt-scala-module (nor sbt-version-policy) itself.

We can merge this PR but the next release of sbt-scala-module should be 3.0.0.

[SethTisue]

the next release of sbt-scala-module should be 3.0.0.

why?

[julienrf]

That’s because the next release would not be binary compatible with the previous release, by transitivity. Indeed, the next release will depend on MiMa 1.x, whereas the previous release depends on 0.9.x. Consider a situation where there is a first lib that depends on the previous release of sbt-scala-module, and a second lib that depends on the next release of sbt-scala-module. We want to make it impossible to use both in the same program since this would lead to having only MiMa 1.x on the classpath, which would not work with the first lib. The idea of sbt-version-policy is that we should signal such incompatibilities upfront by bumping the major version number of sbt-scala-module.

That being said, you are not the first person to seem skeptical about this approach. Also, I think even if the next release of sbt-scala-module is say 2.4.1, a program using the two libraries of my above example would fail to build because sbt would report the conflict for MiMa instead of reporting it for sbt-scala-module…

I hope I am clear, let me know if this is not the case 😄

[SethTisue]

but I don't think we even care about binary compatibility of sbt plugins?

(regardless, I don't really care about the version number, this plugin is only used in a fairly small number of repos, so any signaling the version number does is basically just us sending signals to ourselves)

[julienrf]

I think we should, there are libraries like others, no? I guess they are all loaded in the same classpath?

[SethTisue]

well, it seems somewhat farfetched to me that somebody would have two plugins in their build that would both bring in MiMa. but regardless, going to 3.0.0 costs nothing, so I don't object

[SethTisue]

I'm about to PR the dropping of sbt-travisci (as part of scala/scala-dev#785), so that takes us to 3.0.0 anyway :-)