This thread is for updates and discussions about the eventual Scala 2.13.17 release.
As of yet, we don’t know much about the release’s likely contents or timing. If no followup to 2.13.16 needs to be rushed out, then a typical timeframe might be 3–6 months.
Unless some new incompatibility is reported, there isn’t anything further to do.
(Though are there are new Java language features that the Java parser should support? That’s always desirable to do, and let’s make sure there are open tickets on each of them, but it doesn’t drive release schedules, either.)
Ah, okay. I see the scheduled GA date for JDK 25 is September 2025. I’m sure we’ll have support in nightlies sooner than that (we’ll upgrade ASM as soon as an upgrade is available), but I don’t see this as creating a need to rush out a proper release any earlier than September. People who want to do early testing on JDK 25 can use a nightly Scala.
Regardless, thanks for bringing it up; we’ll definitely keep this in mind as the year progresses.
Yes that still seems reasonable. Are you waiting for #11068?
The nightlies already use ASM 3.8 (which supports JDK 25) and we’re testing 25-ea in CI. For more complete testing, we should add 25-ea to the community, and we could wait for the final JDK 25 release.
On the other hand, having 2.13.17 out before JDK 25 final would allow people to upgrade more quickly.
Yes, but I am in no rush. I only wanted to know how to plan my time
(I am using nightly on some Chimney branch, so I know that is works but because of Scala.js and Scala Native some jobs are failing even with some hairy workarounds. I was just curious when I’ll be able to use some proper solution and release the next milestone basing on the PR. Scala 2.13 users can still use 1.x branch and Scala 3.7+ users received 2.x milestone using Scala 3’s counterpart to this PR, so there is no pressure.)
I started winding down the PR queue for 2.13.16, reassigned most PRs and tickets to the next milestone.
There’s still a bit of time to get something in (in particular there are a copule of open tickets for tasty reader). We might start working on the release in about two weeks.
We have a release candidate: 2.13.17-bin-98a15e6. The community build is green, it was tested on all JDK 8+ LTS versions, including the final JDK 25 release.
As announced recently there is a new resolver that can be used to access Scala 2 and Scala 3 nightly / mergely builds:
Confirming Scala Native altough I was surprised by changes to scala.util.Using - it’s tests were once copied to Scala Native leading to failures under the new suppression behaviour. No other issues found beside this one.
A few more changes were merged, the only relevant one is that we reverted JLine back to 3.29. The latest nightly build is 2.13.17-bin-0744129.
I looked at better support for Java 25 “simpler main methods” today (adapted @eed3si9n’s work on the sbt side), so that we can discuss wheter to include it. @SethTisue suggested it’s fine waiting for the next release. Since this PR is about running simpler main methods through sbt, I agree. Using them in scala-cli seems more common, and that doesn’t need any change in the Scala compiler / release.
Confirming again, everything is fine with 2.13.17-bin-0744129 in the Scala Plugin for IntelliJ repo. Looking forward to the release next week. Thank you.
Not sure if that’s the right place to report this but one project of mine is failing to compile with Scala 2.13.17 (RenovateBot suggested the upgrade).
I can’t reproduce the error in a simple scala-cli script but this does fail to compile with Maven and scala-maven-plugin (4.9.6).
Minified code:
//> using scala 2.13.17
//> using dep com.softwaremill.sttp.client::core:2.3.0
import sttp.client._
implicit val sttpBackend: SttpBackend[Identity, Nothing, NothingT] = ???
val someUrl = "http://example.com"
val response: Identity[Response[Either[String, String]]] = basicRequest.post(uri"$someUrl").send()
Error I get when compiling with Maven (on the last line):
a type was inferred to be kind-polymorphic `Nothing` to conform to `F[_]`
We’re seeing this too, I had to explicitly pass [F] in a bunch of function calls. I don’t have a minimal example but can try to assemble one if more information is needed.