Each time there is a compiler release there is a lag before tooling catches up, and in the case of the recent Scala 3 TASTY format upgrade there was a brief lag before a compatible Scala 2 release was available. The end result is frustration from the user standpoint when they can’t upgrade because tooling support isn’t there (or have to roll back scala-steward upgrades), and pressure on tooling maintainers to get new versions out quickly. I’m wondering if there is any way to embargo releases to take some of the pressure off of tooling maintainers and make these things go more smoothly. This would apply to both Scala 2 and Scala 3.
One possibility might be releasing first to a repository that’s not generally used by end-users, to make the final compiler version available to people working on tooling.
Wondering if anyone has thoughts on this problem and potential solutions.
I don’t think that hiding release artifacts would be the right thing.
Let’s take this 2.13.7 release. I believe there are a lot of users who don’t use scalameta/scalafix/bloop/metals, so it would be incorrect to add delay for them.
I agree that the current state isn’t perfect and there are ways how they might be improved but I wouldn’t say that they are totally bad. I have a feeling that majority of PL should have similar issues.
For example, from Metals viewpoint, there are ways to decrease this delay but it will take a significant time to improve it. But even in the best case, there might be a delay in 1-2 days.
In addition, some completely unpredicted things might happen, like Github Actions outage after compiler release.
So, having all these things, I would propose to separate artifacts publishing from a fully announced release.
For example, we could make a list of projects which release is required before compiler release will be fully announced and Scala Steward will start sending PRs with scala version upgrade.
This actually used to be the model followed by Scala releases several years ago. Back when Scala Steward wasn’t there, there was effectively a 2-3 week-long period between the artifacts being published and the release being announced. During that period, the new version was only communicated through the channels that were the equivalent of what Contributors is today. That gave time to tools and compiler plugins to update before the public announcement.
I would highly welcome the return of such an approach. I’ve been insisting for each version of Scala.js, for example, that artifacts on Maven Central != announced release. We publish release notes up to several days after the artifacts, and in the meantime Scala Steward opens PRs everywhere without any release notes available. We should be able to tell Scala Steward that it must wait until the release announcement before opening PRs.
I agree with the sentiment they releases should be fully announced once the crucial ecosystem has caught up.
From a practical point of view, I think it would be very good to gate Scala version updates from scala-steward until the release is official (and make them opt in if you’re compiler plug-in maintainer, or similar)
Why can’t tooling devs track nightly or something, at least close to release time? Then their codebase would be ready for the release and they could wrap it up right away.
The separate question is if they could, should they feel they have to. Perhaps if they won’t be available during the right time window, either Lightbend could wait or they could step in to help.
But I don’t see why “it takes work to port bloop from 2.13.6 to 2.13.7” translates to that work being done after 2.13.7 is released.
Of course they couldn’t release the final version until there was a final 2.13.7 to put in their dependencies. My point is the kind of things that have to happen after it’s released should be on the order of hours, not days or weeks. And for that, yes the pubic announcement and Scala Steward should wait on that.
Or Scala Steward could be more fine grained. For instance it could be smart enough to know to send the 2.13.7 PR to JVM-only projects earlier and scalajs projects only after that is released for it. The question is what signals it should use.
This doesn’t work for any use cases, notably for compiler plugins, which must publish an artifact whose name includes the exact version number of Scala that they are built for. So if they are built for the “GA” version, they’re still not built for the real version.
So if they are built for the “GA” version, they’re still not built for the real version.
That is sad, but at least the next build could be automated with the said Scala Steward? For example, x.y.z-GA release of some plugin is manual because it requires some changes, tests and check, but as soon as x.y.z is out, plugin release for x.y.z could be automated because it only requires change of used Scala version?
At that point it’s the same as tracking the nightly build in the repos that want to do that. So you’ve not gained anything.
Plus, this still requires some intervention of the maintainers after the official release. If the maintainer is on a week-end, or on vacation (like I was last week), you’re still stuck and users still complain that stuff isn’t actually available at the time of release.
I like this idea. What is not clear to me yet is how it should be implemented. The question is how a published JAR can signal Scala Steward that it has been announced. The most promising solution I can think of is adding the announcement URL and maybe an expiration date to the POM. Scala Steward could then check the HTTP status code of this URL and consider it not announced until it returns 200 or is expired. Would this work for Scala releases and would Scala maintainers willing to put such a URL into the POM?
At that point it’s the same as tracking the nightly build in the repos that want to do that. So you’ve not gained anything.
Maybe, but it differs from nightly builds in a sence that it is ‘official’: “It’s not a nightly build, it’s not a milestone, not a release candidate. There will be no more release candidates or nightlies for this version between GA and release. Actually, it is the release, just postponed for a set amound of time for a maintenance issues.”
If the maintainer is on a week-end, or on vacation (like I was last week), you’re still stuck and users still complain that stuff isn’t actually available at the time of release.
Back to your original post:
In this case, number of ‘good samaritans’ still will announce it via reddit, twitter, discord, etc. and people will start upgrading and complaining like it was a couple years ago. And common answer will be “but the actual release was not announced though the proper channels!” and more complaining.
Well, that was just my two cents for this problem, I sincerely hope that some solution will be found.
Well, at least back then I wasn’t pressured into releasing Scala.js within an hour of Scala compiler artifacts being on Maven Central. And that, irrespective of the day of the week, or the hour of the day or night.
Hey @fthomas,
First, let me say that I believe Scala Steward is one of the most helpful tools in the Scala ecosystem, so thank you so much for that!
I am going to propose a solution that would not be applicable to other JARs, but what do you think of the following? We are on the verge of including the “promotion of new Scala releases” to installers such as SDKMAN (see here) or Coursier, as part of the release process. If we implement that, maybe Scala Steward could check that a Scala release has been promoted to them (e.g., to SDKMAN) before creating PRs?
Does this principle still hold if the repository is explicitly a pre-release repo set up so plugin authors can ready their releases to coincide with the general release?
That would work but I’m not enthusiastic about a solution that only works for the Scala compiler and not for sbt, Scala.js, or any other library. If we cannot find a solution that works for everybody, I think it is easier to implement time delays for new PRs (Time-based delay configuration for new dependencies · Issue #1581 · scala-steward-org/scala-steward · GitHub) and set default delays for Scala, sbt, and Scala.js. Scala Steward would then for example create PRs only a week after the JARs have been released.
