Addressing SIP-51: Include Scala version updates where they are essential?

[rtyley]

Background

• Scala Improvement Proposal (SIP) 51 was a proposal created in December 2022 to "Drop Forwards Binary Compatibility of the Scala 2.13 Standard Library" - the proposal explained that this would make improving the Scala standard library easier, and was approved.
• sbt v1.10.0, released May 2024, included an update to respect this: a project's scalaVersion can no longer be a lower 2.13.x version number than its transitive dependencies

Problem

This leads to Scala Steward raising PRs like these, updating third-party Scala libraries, that immediately fail CI because those libraries are now compiled against newer versions of Scala.

• Update play, play-ahc-ws, ... to 3.0.10 guardian/pan-domain-authentication#224 - failure
• Update play, play-ws to 2.9.10 guardian/pan-domain-authentication#223 - failure
• Update play-ahc-ws, play-filters-helpers, ... to 3.0.10 guardian/tagmanager#590 - failure

Note that Scala Steward did provide a separate PR to update the Scala Version:

• Update scala-library to 2.13.18 guardian/pan-domain-authentication#218

Enhancement

Could we somehow fold in the update to the Scala Version into any PR that requires it?! How could we figure out if a given update requires a newer version of Scala?

[mzuehlke]

I like the suggestion,
but my idea would be to not create these PR in the first place.

When using coursier to find newer version we could use the sameVersions parameter: coursier/sbt-coursier#490

One thing make the whole story a bit more complicated:

• What should we do about Add setting to allow demoting the SIP-51 build failure sbt/sbt#8012 which added allowUnsafeScalaLibUpgrade
• A github search suggest that this isn't used very often and could be added later if needed