This release improves the JVM backend (bytecode generation), adds parsing of Java records to the Java parser and brings a lot of bug fixes.
A stable release or a next RC can be expected around July 10th.
This shifts the planned date of the stable release to July 17th.
This release reverts a commit that was causing a regression in the RCs.
This shifts the planned date of the stable release to July 19th.
We still have two unsquashed bugs that we really want to get rid of before releasing 3.3.1: #17245, #18163. Next week we will release the next RC with fixes for them and a few other small changes, such as a fix for #17293.
It’s done when it’s done.
Better solid than rushed!
The newest release contains quite a lot of fixes to assure not only binary but also source compatibility with 3.3.0.
You can find release notes on GitHub.
Would it be possible to provide a rough ETA for Scala 3.3.1, I noticed that the artifact for
-RC6 is almost ready (see 3.3.1-RC6 Release procedure · Issue #18439 · lampepfl/dotty · GitHub)?
The reason I am asking is that we are trying to plan releases around Pekko (specifically Pekko connectors) and our JDBC connector is blocked by Slick Scala 3 release (which is waiting for scala compiler crash that is fixed in Scala 3.3.1)
From the results of the last community builds it looks like RC6 will be the last release candidate.
The plan is to have 3.1.1 artifacts ready on Maven Central on Friday, September 1st. The release will be announced in the following week. If no new significant regressions are found (which at this moment is very unlikely), the release procedure will end before Friday 8th. I’ll confirm the plan on Monday after the compiler team’s weekly meeting.
This release contains fixes for two regressions and reverts #17457 that was causing problems with maintaining source compatibility.
#17457 will be a part of Scala 3.4 and may be backported to some future Scala 3.1.x release when we find solutions for its current problems.
We will need to release 3.3.1-RC7.
There are two outstanding source incompatibilities in RC6. The first one is a classic situation where two bugs canceled each other perfectly in some cases, so the compiler was working correctly. Recently, we have fixed one of them, revealing the other one that was with us since before the 3.0.0.
The other change is a reversal of adding the new experimental constructors for
FunctionClass in the quotes API. It turns out that adding experimental overloads can sometimes lead to breaking the source compatibility.
It shouldn’t delay the release announcement of the full release of 3.3.1. While we will not have release artifacts on Maven Central before Tuesday, September 5th, the release announcement will still happen before next Friday.
The changelog can be found here.
What about issue find-member recursion · Issue #18263 · lampepfl/dotty · GitHub that was only exposed in 3.3.1-RCx due to compiler changes, but exists in all 3.x.x releases?
RC6 reverted #17457 that exposed this bug. I checked, and DFiant is passing a compilation both with RC6 and RC7.
#18236 will be fixed in some later version.
Did you try
Test/compile or just
compile? Because on my computer it fails. I’m not sure that #17457 is the one that surfaced this bug.
Maybe the community build only invokes
compile but not
If the OpenCB runs
sbt test, then everything should compile.
Unless tests do not compile in any version of Scala (build issue, typos, etc.) we do run separately
Test/compile. On top of that there is also building the docs and runtime test
Test/test if not explicitly disabled if tests are flaky or require dedicated infrastructure (eg. test-containers).
We have observed this in Open CB but AFAIR the issue in
Test/compile was not related to the one found in
Compile/compile. The issue was raised, but AFAIR it was not yet decided it we would be able to fix in 3.3.1 which is already late on the schedule and is blocking some other projects.
Build logs should probably show the same issue you’ve spotted.
I understand. It’s just an LTS maintenance and release policy question. If a project successfully compiles on 3.3.0 and not on 3.3.1 and we already know this during the 3.3.1-RCx period, then is the best policy to push it forward anyway or fix a regression and wait a little more? Granted, this regression is a result of a change that exposed a pre-LTS compiler bug that was hidden, but still is a regression from an LTS user perspective.
I’ve added the not yet minimized reproducer. I’d suggest to move the further discussion on this regression to the issue