Should scala-steward stop recommending to upgrade Scala 3 minor versions?

[jodersky]

Scala 3.x is backward compatible, but not forward compatible. For example, this means that a library built with 3.0.2 can be consumed by a library built with 3.1.0, but NOT the other way around (See https://twitter.com/SethTisue/status/1450260785762947076 for some more info). Considering these compatibility semantics, should scala-steward by default stop recommending to upgrade scala versions if they are >= 3?

I think that there will be little disagreement that for library developers, the best practice is to be conservative and indeed use the lowest Scala 3 version as reasonably possible (3.0.2 as of this writing). End-user application developers may have more liberty, but even then I am not sure that the benefits of always using the latest Scala version are that important. Hence, unless there is a way for projects to indicate to scala-steward if they are a library or application, I would recommend that the default behavior should be changed to not upgrade Scala 3 versions beyond the newest patch-level.

[fthomas]

My understanding from https://github.com/scala/scala-lang/blob/5303453ebe4d1597adce544871f6712e217cff19/blog/_posts/2022-01-17-scala-3.1.1-released.md#312-rc1-and-forward-compatibility-improvements is that library authors can use the latest Scala 3 version if they set -Yscala-release=3.0. I think it is fine then if Scala Steward keeps proposing the new Scala 3 versions.

[jodersky]

That is an interesting blog post, I was not aware of this new flag. IIRC the -Y flags are private, so I'm not sure how stable this flag will be. If it does end up being a stable feature, then I agree that it would nullify this issue.

[fthomas]

Here is a new blog post that is relevant for this issue: Long-term compatibility plans for Scala 3

[mzuehlke]

In light of the last blog post mentioned by @fthomas I see no reason to build some special handling for Scala version upgrades into Scala Steward. If a project wants to restrict upgrades of Scala 3 it can pin a specific minor version:

updates.pin = [
  { groupId = "org.scala-lang", artifactId="scala3-compiler", version = "3.1." },
  { groupId = "org.scala-lang", artifactId="scala3-library", version = "3.1." },
  { groupId = "org.scala-lang", artifactId="scala3-library_sjs1", version = "3.1." }
]

(taken from https://github.com/scalameta/mdoc/blob/42fcf08fab1f622ea5c229a77e5b08af2f272a55/.scala-steward.conf#L8-L12)

[fthomas]

Using updates.pin to pin Scala updates to Scala LTS versions sounds a like a good solution to me. It would also be nice if not everybody would have to copy the five lines above into their .scala-steward.conf and maintain them (e.g. updating the version if a new Scala LTS is released). It would be cool if something like a pinScalaLTS variable could be defined in our default repo configuration which people would use in their own .scala-steward.conf and which is expanded to the snippet above. Unfortunately, I don't think is is possible right now.

[SethTisue]

this is freshly relevant now that the 3.4.x series, the first post-LTS Scala 3 releases, has begun

not sure whether change is needed on the Steward's end, or whether it's sufficient for the Scala 3 release steps to be updated to account for this (as I just also suggested on #3302) cc @Kordyjan

[mzuehlke]

I took a look at the current Steward behaviour and what is possible using the configuration
(I looked at #3302, #3153 and #3285, too):

Using pin in default.scala-steward.conf

updates.pin = [
  { groupId = "org.scala-lang", artifactId="scala3-compiler", version = "3.3." },
  { groupId = "org.scala-lang", artifactId="scala3-library", version = "3.3." },
  { groupId = "org.scala-lang", artifactId="scala3-library_sjs1", version = "3.3." }
]

Users that want 3.4 would have to adapt their local .scala-steward.conf to pin scala to version 3.4..
Once 3.5.0 is out, we could add that to the default pin. Then user who manually pinned scala to 3.4. would then either need to remove their pin or add 3.5. locally, too.

The only disadvantage I can see is that there would be no more updates to users on older Scala version (3.2.1-> 3.2.2) but I am not sure if this is still relevant. If so I guess we could add 3.0., 3.1. and 3.2.too the list of pins.

BUT when trying this out I think I discovered a bug with respect to merging default and local settings. I will open a PR in a minute.