I would like to discuss the timing of Scala releases.
Since the libraries I’m maintaining are at the bottom of the dependency chain, I feel I have less stake in this and can therefore approach the issue more objectively.
The latest Scala 3.0.0 release occurred right before the weekend, so then all ecosystem maintainers are “forced” to work on the weekend or lag behind. What time is it best to release in? During the start of the week, so maintainers utilize workdays(/evenings) to push new releases or alternatively to allow them to utilize the weekend? I don’t know what the best approach is, as most of the community maintainers are volunteers, but I do think consistency matters.
I think a good approach is to conduct a survey among maintainers and get an idea what the community wants. Then, choose constant weekday for compiler releases. If the day is missed during the compiler release preparation, then the compiler team would wait another week. The same goes if a holiday is occurring on the release day.
Maybe since future releases are binary compatible it’s not a big deal, but there are teams that still need to keep up (e.g., the Metals team), and I think this proposal would make things easier for everyone. Unless there is an urgent security fix, I don’t think anything merits exhausting the community needlessly. We can wait another week.
What do you think?
Edit: as @bjornregnell suggested, I created a short survey (just two questions).
I think this sounds like a good idea. Knowing that new Scala releases are always done with a consistent date rule would be good (e.g. the first day of a week that is not on a bank holiday).
@soronpo Why don’t you just open a simple survey with a link posted here and then report back here how it went? Then if the proposal seems getting traction among maintainers the Scala team as good input when fine-tuning the future release process.
The principle makes sense, but I wonder if this was a first-release effect. That rarely goes smoothly, but I suspect it’ll work better in subsequent releases.
So I’m not sure this is an ongoing problem, so much as initial teething pains…
The artifacts of Scala 3.0.0 were released on Wednesday. That was precisely done to allow a couple of weekdays for core libraries and tools to be published.
The announcement was scheduled for Monday (the day after tomorrow), precisely for the reasons you outline. But people got crazy about the git tag instead of waiting for the announcement, it ended up on the top of Hacker News, and that forced the release on the announcement on Friday (yesterday).
So there you go. We already had the policy to release at the beginning of the week. But the community decided otherwise.
I’ll clarify. Announcements tell the public, “the release is here and ready to use”. But if no tools and libraries are ready, then it’s not actually ready to use. So the current policy is actually doing what I want to avoid- putting pressure on the community to make things work over the weekend until the upcoming Monday message.
So what I’m proposing, push-tag on Monday, and then make an announcement a week after.
Again, it was on Wednesday. Perhaps not Monday, but not Friday either. It was planned. We did give the maintainers of core tools the time they requested. We double checked with the Metals team in advance, in particular.
You can choose any day of the week, the story will repeat itself. We’ll push a tag on Monday, the word will somehow get out a few days later (you can never predict how long it will take; it’s different every single time), and no matter when you planned the tag and/or the announcement, there’s a 50/50 chance that it will become publicly widely known at the end of the week or during the weekend. We’ve tried several timings during the RC cycle. None was predictable. This doesn’t work.
