Fewer unstable releases: only alpha, beta, and rc. beta is equivalent to our old .90 releases, and rc is equivalent to our .92.
Later .1 stable release, scheduled for early May, after Ubuntu 21.04 and Fedora 34 have been released. The goal here is to improve the quality of our initial stable release to ensure it is really release-ready. Distributions are encouraged to begin testing 40.alpha and 40.beta as soon as possible, to find bugs earlier than we have in the past.
The severe reduction of releases goes against the ‘release early, release often’. I hope it’ll be ok. Having maintainers spend a lot of time can be a good thing. Still good to try it and perhaps evaluate after 40.
Other than that, maybe put GNOME Asia (online) event in there, it’s around the time of some 3.38 and 3.36 stable releases. https://events.gnome.org/event/24/
Those CI releases aren’t getting to the usage that a tarball would. At least not in the way that you have distributions trying to package things, discover bugs. Then additional users, etc. It makes quite a bit of difference if it’s a CI, then packagers, then the users of an unstable distribution, then finally the users of a stable distro. Each time you greatly increase the users they’ll discover things that went unnoticed before.
So there’s a risk there. I’m not saying not to try it, I might be completely wrong and there wasn’t always a CI infrastructure.
Very, very few people ever used those tarball releases, and since we’re building core applications as part of our CD pipeline, and since non-core applications are now continuously built against the flatpak run time that the GNOMECD pipeline generates, I’d contend that the extra alpha/beta/rc releases only ever helped distro packagers to check a box. Adding more releases, on the other hand, creates a lot of busy work for maintainers and for the release team.
Additionally, fewer releases imply a bit more time between them, giving downstream distributors more time to test issues and propose fixes upstream before the first stable release.
Yes, there’s a quantifiable risk when changing a long-standing policy; we’re probably going to need a couple of cycles to get everything hammered down. I’d still want to wait a while before changing cadence again, and give time to downstream distributors to adapt.
I package GNOME for Mageia. Quite a lot of people use those tarball releases once they’re packaged. It’s not in any way comparable to e.g. a Fedora stable release, but in case of issues they’ll quickly catch it. They’ve also found a lot of issues I never noticed, or thought it was just my system or something I caused. It does depend though; the early
Regarding CI: sometimes stuff is forgotten. Meaning, the CI is configured to e.g. use git / add a patch / something. However, then the tarballs miss that. Or when it needs a new version of some dependency but the build system didn’t have it.
Note that looking at the previous amount of releases, I did rely on previous tarball creations to sort out the tarball issues. For Mageia I usually start packaging a bit after the unstable.3 release. So e.g. 3.37.1, 3.37.2 I’d ignore. So .3, .90, .91, .92 would be packaged, and I’d rely on “GNOME” doing a complete tarball build of .1 and .2 to sort out any early issues.
So perhaps you’re right regarding .1 and .2 (not used a lot), still feel a bit uneasy as I do wonder if more things will now only be discovered while packaging. The efforts of the release team prevent packagers from discovering things.
So the only release not there anymore is .91, which was only two weeks separated from both .90 and .92. The goal here was to encourage developers to focus more on the quality of the beta release (.90). Currently there are so many development releases that many developers ignore almost all of them. Lots of developers currently skip .3, .90, .91, even .92. Having fewer releases should hopefully help us emphasize their importance and create an expectation that every core module gets released at these points. The goal is to encourage early testing of changes, not to discourage it.
For what’s packaged, there’s one release difference indeed. But it also helps to have different sized groups of people look at things. So including having a release despite not packaging it. I do fear the initial alpha quality will go down a bit because I do see additional work, it’s not just savings in time.
Regarding testing and found bugs, it usually increases with the amount of people using it. So for unstable stuff I usually have the following thought: 1-3 users/testers (developers and no tarball), 10-30 testers (release team bit for e.g. 3.37.1 and 3.37.2), 100-200 testers (first distro to package it, hopefully 3.37.2), 1000+ testers (multiple distros with 3.37.3), etc (stable distro, etc).
I don’t want to takeover the stuff that could’ve been caught with a much smaller amount of testers. Also, if the release is too unstable it’ll not go over well with the distribution users.
There’s sometimes a few cases where instead of a 3.x.y.1 as a packager you have to figure out that there was a patch. IMO that’s unneeded.
If the goal is to get every release tested at every point I think the amount of work might actually go up for a release team, not down. I see time saved, but also time which needs to be spend.
Anyway, I’m not intending to want to repeat the versioning discussion, nor that anything is changed at this time. Just that it’s kept in mind.
According to this schedule, the string freeze starts exactly in the middle between the beta and rc releases, and is not tied to a particular release. I’m don’t know if the i18n team would want to change it, but it might be worth asking them explicitly.
(I recall they didn’t want string freeze to start at the same time as The Freeze when the freezes were merged, but it might be different now that we have usable nightly builds of GNOME)
I don’t remember what the arguments were at the time and that would be helpful to know before forming an opinion. I’ll try and dig in the archives, but if someone finds it before then, don’t hesitate to share the link here.
I couldn’t find it either: I found this thread where i18n agrees to have string freeze as part of The Freeze, but the subsequent proposal and the final announcement said to keep the string freeze where it is.
IIRC, the reasoning was that most translators will start translating after the freeze and it’s more likely to find errors in the original strings shortly after the freeze.