Scala 3.5.0-RC1 is ready for testing, and it’s big!
First, it implements SIP-46. Scala CLI will be your default runner when you install Scala using sdkman, homebrew, or other package managers. You can test it now by getting Scala from the GitHub release page. Currently, it requires JVM 17 or newer. This won’t be the case in the stable release, as we will provide native launchers for multiple systems in one of the future RCs.
The second highlight of this release is the introduction of Best Effort Compilation and the BETASTy file format. All tooling maintainers had long awaited this improvement. They can now access complete information about code structure in the projects that are not passing compilation at the moment. In a few weeks, a small error in an unrelated file causing Metals not to offer useful autocompletion will be a thing of the past.
Support for the pipelined builds was also added. It significantly decreases compilation times for most of the big projects.
Smaller but still significant changes include support for binary literals and allowing vars in refinements.
For more info, see a changelog on the already mentioned release page.
We plan to go slowly and carefully with this release. Expect further release candidates. The stable release will not come before July 2nd.
I don’t think any action is necessary here, scala and scala-cli are installed separately so don’t clash. However, if you previously installed scala-experimental with coursier, you might want to uninstall that.
cs setup has not been changed - it will still install scala-cli and scala commands. The scala command installed will be 3.4.2 however - because that’s the latest stable version.
When scala 3.5.0 (stable) is released then cs setup will still install a scala command, but this will launch scala-cli underneath.
if you do cs install scala:3.5.0-RC1 now, then it should install a scala command based on the jar launcher for scala-cli (requires JVM 17+, we will switch to native launchers by 3.5.0). You also will probably have to update coursier/cs commands first - to make sure you resolve the correct artefact.
here is scala version output:
$ scala version
Scala code runner version: 1.3.1
Scala version (default): 3.5.0-RC1
Important
If you don’t update cs first, then might not understand that it needs to install the scala-cli launcher - so you could get this output instead:
$ scala version
[warning] MainGenericRunner class is deprecated since Scala 3.5.0, and Scala CLI features will not work.
[warning] Please be sure to update to the Scala CLI launcher to use the new features.
[warning] It appears that your Coursier-based Scala installation is misconfigured.
[warning] To update to the new Scala CLI runner, please update (coursier, cs) commands first before re-installing scala.
[warning] Check the Scala 3.5.0 release notes to troubleshoot your installation.
Ignoring spurious arguments: version
Welcome to Scala 3.5.0-RC1 (21.0.2, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.
scala>
the logging output will point you to update coursier/cs anyway
when I run scala install-completions then my .zshrc is updated as follows (macOS):
Another caveat - from Scala 3.5.0-RC1 and up, nightly versions of scala command aren’t available to install directly from Coursier (still works for scalac, scaladoc), instead, use the -S flag (alias of --scala-version) of the scala command.
Don’t do
$ cs install scala:3.5.0-RC1-bin-20240520-8563571-NIGHTLY
No prebuilt binary available at https://github.com/scala/scala3/releases/download/3.5.0-RC1-bin-20240520-8563571-NIGHTLY/scala3-3.5.0-RC1-bin-20240520-8563571-NIGHTLY.zip
Do this instead (New workflow)
$ cs install scala:3.5.0-RC1
wrote scala
$ scala -S 3.5.0-RC1-bin-20240520-8563571-NIGHTLY
Welcome to Scala 3.5.0-RC1-bin-20240520-8563571-NIGHTLY-git-8563571 (21.0.2, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.
scala>
or better yet
$ scala -S 3.nightly
Welcome to Scala 3.5.0-RC1-bin-20240520-8563571-NIGHTLY-git-8563571 (21.0.2, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.
scala>
in my tests on a warm JVM, that just look like c;clean;c;clean;c;clean;c;clean;c;clean;c;clean; , I find that 3.5 compiles lila in 42s without pipelining, and 38s with pipelining
so, about 10 % reduction on build time.
It was about 41s on 3.4.2.
Also We did a lot of refactor toward diamond architecture few months ago to optimize our build time.
p/s: I don’t know how I fck up the timeline
p/s 2: fixed it
if we wanted to backport pipelining to 3.3 there would have to be a redesign, e.g. perhaps using a different file extension for tasty files - which would not be practical for mixed scala 2 and 3 projects.
It is not July yet, but given there is no 3.3.4 RC or any visible activity on this front (last commit to GitHub - scala/scala3 at release-3.3.4 was 2 months ago), I doubt this will happen.
Expecting them, but so far in vain. I understand things rarely go as expected, it is the lack of communication I find disturbing (and to me this is unfortunately a sign of deeper project management issues).
We’re working on it and need a bit more time. Sorry that we haven’t made it on time. We’re in the long process of backports and regression tests right now, but we’ve secured resources to ensure we can finish it quickly.
We’re going to start the release procedure for 3.5.0-RC2 tomorrow. The next LTS release might require at least 1 additional week.
at least should have a milestone created with 3.3.4 and added all the backports to that milestone
Milestones are not used for backports with the exception of RC backports. In general milestones are rather used to group issues/prs required for next Scala Next release until it’s cut-off date. Instead, we use a dedicated GH project and dedicated tooling to streamline the process of backporting to the LTS scala3/project/RELEASES.md at main · scala/scala3 · GitHub
Yes, but it requires some time. When backporting we try to follow the order of changes in the main branch to reduce the amount of conflicts. There is a long queue so please be patient, we’re working on it.
