Defaults for Xsource are not binary compatible between 2.13.12 and 2.13.14

[jenshalm]

The changes associated with this flag have the unfortunate effect that for some projects (like Laika) both sticking with the old Xsource:3 or switching to the new Xsource:3-cross can lead to breaking bincompat which will be flagged my mima. The reason is that the old flag does less now than it used to do in 2.13.12 while the new flag does more and the respective differences in feature support are both bincompat-breaking for any source that contains the affected features. The solution for Laika was to use the new flag -Xsource-features to selectively enable those features from Xsource:3-cross which used to live under Xsource:3 in 2.13.12 (see https://github.com/typelevel/Laika/commit/0d88951cd10d6b777c4f055f017d942d8a27f09e#diff-5634c415cd8c8504fdb973a3ed092300b43c4b8fc1e184f7249eb29a55511f91R54).

Now given that sbt-tl sets Xsource:3 by default it effectively means that it sets a default that is potentially bin-compat breaking for projects going from 2.13.12 to 2.13.14.

The behaviour of the Xsource flag is described in detail in this page: https://docs.scala-lang.org/scala3/guides/migration/tooling-scala2-xsource3.html - however, it unfortunately lacks a migration guide for projects which used Xsource:3 in 2.13.12 or earlier. It explicitly lists 3 features affecting bincompat: case-apply-copy-access, case-companion-function, infer-override. For Laika I validated that infer-override needs to be on, while case-companion-function needs to be off, which can be accomplished by keeping Xsource:3 (which does not contain any of those 3 features) and additionally set -Xsource-features:infer-override to add the removed feature back in. I am not sure about the 3rd feature which would need to be investigated (case-apply-copy-access).

The risk for projects using sbt-tl to publish artifacts that are not bincompat is fairly low, as mima seems to reliably flag all those issues. However, it would be more convenient and consistent if the plugin would ensure compatibility under the hood. The ideal solution imho would be:

• For 2.13.14+ set additional flags automatically to mimic the old behaviour of 2.13.12 or earlier.
• For 2.13.13 emit a warning, imho no project should publish with that version as the new Xsource-features flag does not exist in that version, making it impossible to guarantee bincompat between 2.13.12 and 2.13.13