Update sbt-scala-native, scala3lib to 0.4.10 (and drop Scala 2.11 for JS and Native)

[scala-steward]

Updates

• org.scala-native:sbt-scala-native
• org.scala-native:scala3lib

from 0.4.9 to 0.4.10.
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!

Adjust future updates

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

updates.ignore = [ { groupId = "org.scala-native" } ]

Or, add this to slow down future updates of this dependency:

dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scala-native" }
}]

labels: library-update, early-semver-minor, semver-spec-patch, commit-count:1

[SethTisue]

Scala Native no longer supports 2.11. There is no Scala Native ecosystem to speak of on 2.11, so I think we should take this upgrade — we just need to adjust the build to drop this entry from the build matrix.

[SethTisue]

I think we could also drop Scala.js on 2.11, since they've dropped support.

But I think it would be a bit rude to do it in a patch version, so let's bump our minor version number.

[julienrf]

In general, what is the motivation for updating Scala.js and Scala Native?

The problem I see is that it forces the users of scala-collection-compat to also update their version of Scala.js and Scala Native. I think we should aim for the opposite: scala-collection-compat should be compatible with as many versions of Scala.js or Scala Native as possible. Unless we are affected by a bug or a security vulnerability, I don’t see a reason to bump Scala.js or Scala Native.

[SethTisue]

In general, what is the motivation for updating Scala.js and Scala Native?

I believe it's considered standard in the Scala.js world (and I guess Native as well? less sure) for libraries to take the upgrades fearlessly — it's considered normal that downstream users might need to upgrade.

Scala.js is pretty mature so there's less likely to be a specific benefit there, but perhaps there is some specific benefit. But Scala Native is still pre-1.0 so it's even likelier that the new version would do a better job.

@sjrd wdyt?

[sjrd]

For Scala.js, our idea is that we offer backward compatibility so that library maintainers don't have to think about it. You want to upgrade? Sure, go ahead, your users won't be blocked from upgrading as well. Want to stay put? That's all right, your users can still upgrade and use your library.

So it's not so much about Scala.js per se; it's more what do you with your other dependencies? Do you regularly upgrade your library dependencies and your Scala compiler? Then it makes sense to upgrade Scala.js as well. Do you stay on the oldest possible version of your libraries dependencies and on the compiler? Then stay on an old version of Scala.js.

[SethTisue]

I think we should take Seb as the authority on Scala.js, and I believe his considerations apply even more strongly to the less mature Scala Native. So I think we should go ahead here.

[sjrd]

So @julienrf asked me to elaborate on my thoughts for the particular case of scala-collection-compat. In general, my advice remains to do for Scala.js as you do for other dependencies. But of course scala-collection-compat has basically no other dependencies, so there isn't another policy to follow. If I were the maintainer of scala-collection-compat, I would choose not to upgrade dependencies in general, because it is very close to the core.

[SethTisue]

Note that we've already taken a Scala 3.2 upgrade in this repo. We can hold off on taking the 3.3 upgrade until the 3.3.x series is mature and well established.

[scala-steward]

Superseded by #585.