3.3.1 release thread

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.

1 Like

Maybe the community build only invokes compile but not Test/compile?

If the OpenCB runs sbt test, then everything should compile.

1 Like

Unless tests do not compile in any version of Scala (build issue, typos, etc.) we do run separately Compile/compile and 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.

1 Like

I’ve added the not yet minimized reproducer. I’d suggest to move the further discussion on this regression to the issue

I already minimized the issue, and mentioned it in my earlier post. See find-member recursion · Issue #18263 · lampepfl/dotty · GitHub

I just wanted to mention that we have decided to release Pekko Connectors with some modules missing because updating to Slick 3.5.0 from Slick 3.3.3 was considered too much of a big change for the first release of Pekko Connectors.

So don’t feel pressured to release Scala 3.3.1 (not that I think that was the case anyways)


During yesterday’s compiler team meeting, we decided to go forward with publishing Scala 3.3.1.

We discussed two outstanding issues.

We wanted to have both of these issues sorted out before the release, but it would further delay multiple important fixes that 3.3.1 is bringing. Both will be fixed in 3.3.2.

The release procedure: 3.3.1 Release procedure · Issue #18515 · lampepfl/dotty · GitHub


Thank you very much for tending to the opened tickets and commitment on future fixes!
Good luck with the release!


I see that 3.3.1 is on Maven Central, and I also see that Scala Steward is sending out version bump PRs, even though the release isn’t announced yet.

For Scala 2, we avoid that by embargoing the new version until announcement time, when the embargo is lifted with a PR such as Release the Scala 2.13.11 kraken! by SethTisue · Pull Request #3075 · scala-steward-org/scala-steward · GitHub . Perhaps similar measures should be taken for Scala 3?


The release was announced yesterday (at least it was yesterday in the CEST terms :wink: ):

Scala Steward was unleashed around the same time:

It is not much different from what we did for the last few patch releases. I remember we agreed sometime before 3.2.2 that the big announcement with separate blog posts would be reserved for minor releases.

I plan to close this thread when the entire release procedure is completed. The only parts that are left are bootstrapping the current main line of the compiler using the newly released version (which is an internal technical task, without any consequences for the language users) and updating g8 templates. I don’t think the templates, unlike tools like Metals or Scastie, should block the release. I think the opposite is better, that they should change the version only after the release.

Maybe the problem here is that the release steps are shown out of order and there is no clear statement of which steps of the procedure are considered to be a prerequisite of release and which are a follow-up to that. Probably we can improve here.


Doh! Okay, but note that I didn’t know about the news item on the web site because it hasn’t been shared on Twitter, or Discourse, or Discord, or Mastodon (I don’t think), or Reddit, or…

1 Like

Ah, but I guess that’s what you mean by this:

I remember we agreed sometime before 3.2.2 that the big announcement with separate blog posts would be reserved for minor releases.

But I must say it feels strange to me. I can appreciate not wanting to spam people, but a huge amount of work went into this release and a lot of time has passed (3 months since 3.3.0). And the release does have new features, not just bugfixes.


…and with setting up 3.3.1 as a new reference version for the current main branch, we finished the release procedure.


I think you made a mistake when you notified sdkman about the latest release, because it shows 3.1.1 as latest stable version instead of 3.3.1:

$ sdk upgrade

Available defaults:
scala (local: 3.3.0, 2.12.18, 2.13.12; default: 3.1.1)

Use prescribed default version(s)? (Y/n): 

Downloading: scala 3.1.1

In progress...

It should be possible to fix that with the /default endpoint of the sdkman api as described here: Vendors - SDKMAN! the Software Development Kit Manager

1 Like

I don’t know why I haven’t received a notification about your comment.

Thanks for reporting the problem. It was reported by multiple people and fixed shortly after.

The sdkman is notified automatically about releases by the CI, and it hadn’t worked as intended this time. This is now fixed and shouldn’t occur in the future.

May I suggest creating a 3.3.2 release thread, to discuss timing and contents?


And if I can nominate a point for discussion, can we make SIP 54 part of the LTS release (enabling same-named extension methods imports from different sources)? In general I would say ‘no’, but this SIP feels more like fixing a bug in Scala 3 rather than a language change.


This new thread has 3.3.2 timing: Scala 3.3.2 release date?