Rolling distribution releases versus periodic releases are a tradeoff

September 13, 2020

In reaction to my entry on the work involved for me in upgrading Fedora, Ben Cotton wrote a useful entry, What do “rolling release” and “stable” mean in the context of operating systems?. In the entry, Ben Cotton sort of mentioned something in passing that I want to emphasize, which is that the choice between a rolling release and a periodic release is tradeoff, not an option where there is a clear right answer.

In the Linux world, fundamentally things change because the upstreams of our software change stuff around. Firefox drops support for old style XUL based addons (to people's pain); Gnome moves from Gnome 2 to Gnome 3 (an interface change that I objected to very strongly); Upstart loses out to systemd; Python 2 stops being supported; and so on. As people using a distribution, we cannot avoid these changes for long, and attempting to do so gives you 'zombie' distributions. So the question is when we get these changes inflicted on us and how large they are.

In a rolling release distribution, you get unpredictably spaced changes of unpredictable size but generally not a lot of change at once. Your experience is likely going to be a relatively constant small drumbeat of changes, with periodic bigger ones. Partly this is because large projects don't all change things at the same time (or even do releases at the same time), and partly this is because the distribution itself is not going to want to try to shove too many big changes in at once even if several upstreams all do big releases in close succession.

In a periodic release distribution, you get large blocks of change at predictable points (when a new release is made and you upgrade), but not a lot of change at other times. When you upgrade you may need to do a lot of adjustment at once, but other than that you can sit back. In addition, if something changes in your environment it may be hard to figure out what piece of software caused the change and what you can do to fix it, because so many things changed at the same time.

(In a rolling release distribution, you can often attribute a change in your environment to a specific update of only a few things that you just did.)

Neither of these choices of when and how to absorb changes is 'right'; they are a tradeoff. Some people will prefer one side of the tradeoff, and other people will prefer the other. Neither is wrong (or right), because it is a preference, and people can even change their views of what they want over time or in different circumstances.

(Although you might think that I come down firmly on the side of rolling releases for my desktops, I'm actually not sure that I would in practice. I may put off Fedora releases a lot because of how much I have to do at once, but at the same time I would probably get very irritated if I was frequently having to fiddle with some aspect of my custom non-desktop. It's a nice thing that I got everything working at the start of Fedora 31 and haven't had to touch it since.)

Comments on this page:

By Legooolas at 2020-09-14 09:39:02:

This becomes quite blurred when there are release-based distros like CentOS/RHEL, which then have point-releases (at unpredictable times) when they upgrade major things like GNOME versions. Pretty much every time this happens, if you have automatic security updates enabled (which don't separate point releases from individual package updates on CentOS), something will break. What fun! At least with rolling releases you know this will happen from the start and plan to have regular testing for updates...

It's interesting that pretty much all of the upstream changes you describe, you describe as negatives: they're not changes made in response to obvious user needs or desires, but in response to internal project concerns that don't line up very well with user needs or desires. Which raises the obvious question: why should users have to put up with all this? Isn't there any alternative that doesn't keep changing things just for the sake of changing them?

By Matt S Trout (mst) at 2020-10-30 09:11:16:

This is one of the reasons I've often been glad for the existence of debian testing - one can treet stable as 'release', unstable as 'hahahaha good luck' and testing as sort-of-rolling but without too much exploding.

Written on 13 September 2020.
« Some notes on what Fedora's DNF logs and where
I'm now a user of Vim, not classical Vi (partly because of windows) »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Sep 13 00:16:33 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.