How are the compilation times?
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
4 Likes
So seems like the lastes version of Scala 3 will always be the best for application development
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.
Yes, it seems so, unless you have a big app and don’t want to deal with of some possible migrations/deprecation.
1 Like
I currently can’t use Scala3 at work, seems there are some issue when compiling with 3.4.x.
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).
1 Like
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.
7 Likes
at least should have a milestone created with 3.3.4 and added all the backports to that milestone
@WojciechMazur Will Java parser doesn't support JEP 409 sealed classes · Issue #18533 · scala/scala3 · GitHub be included in 3.3.4?
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
Will Java parser doesn’t support JEP 409 sealed classes · Issue #18533 · scala/scala3 · GitHub be included in 3.3.4?
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.
5 Likes
Thanks, we are using Java 21 With scala and need this before we migrate to Scala 3.3.x
That is definitely out of policy for LTS. It is a language enhancement, not a bug fix. Moreover, it has a non-negligible chance of breaking someone’s source code somewhere.
4 Likes
This SIP really feels like a bugfix (and several issues posted as bugs are a testament to that), and the likelihood of code breaking in this case is far less than some far reaching fixes I’ve experienced in the LTS release thus far (that DID cause regressions). Something to consider.
I have no particular opinion on whether it’s appropriate to backport to 3.3–I agree it could break code–but I do think that extension methods are a toy feature not suitable for widespread use without the patch in.
So what I really don’t think would be good is messaging of “use extension methods! They’re great!” and also “Use 3.3 LTS!”.
Extension methods are great in 3.4.
Scala 3.5.0-RC2 is now available for testing.
The second RC besides bugfixes includes native binaries for the new Scala runner available for most of the popular platforms.
9 Likes
https://mvnrepository.com/artifact/org.scala-lang/scala3-library_3/3.5.0-RC2
Will the next release upgrade the scala-library to 2.13.14, it currently is 2.13.12
The 2.13.14 upgrade is planned for RC3
4 Likes