3.3.1 release thread

Announcements
21

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

22

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)

2 Likes
23

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

3 Likes
24

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

2 Likes
25

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?

3 Likes
26

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.

3 Likes
27

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
28

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.

2 Likes
29

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

2 Likes
30

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
31

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.

32

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

5 Likes
33

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.

3 Likes
34

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