== Linux distributions have sensible reasons to prefer periodic releases In an aside in my entry on [[why Fedora version upgrades are a pain for me FedoraUpgradeDrag]], I said that there are sensible reasons for for distributions doing periodic releases instead of 'rolling releases'. Today I want to talk about some of them. To start with, pretty much every major Linux distribution practices some kind of rolling development (I don't count Red Hat Enterprise here). No one does a release then goes away to do other things for a year or three before they start putting together the next one; instead, everyone has some kind of rolling, in development collection of packages that are updated on an ongoing basis. As upstream updates come out they generally get packaged and pushed into this rolling collection, and after a while some version of the collection starts to get turned into the next release. However, not all upstream releases and package changes are equal. Some are more disruptive and fundamental than others, either because they're significant changes to fundamental building blocks (such as the C compiler or standard system libraries) or because they're big changes to user visible things (a new Gnome or KDE release). There are also significant changes to the composition of the distribution, such as 'we're switching from Upstart to systemd' or 'we're mostly removing Python 2'. Doing these big transitions only periodically, in new releases, provides Linux distributions some advantages. To start with, you have fewer system states to worry about and to debug; either all your transitions have been applied (in the form of a release upgrade) or none of them have. You don't have to build tooling and do testing for a whole series of successive transitions through various system states ('we have systemd but with Python 2 still around'), and can go for a simpler shift ('systemd and it only has to support Python 3 bindings'). Some of the time you can build specific tooling that runs outside of your normal package updates in order to make these transitions (if you only officially support release to release upgrades through special tools, instead of through package updates). (I suspect it's also easier to document the changes for people upgrading, and easier for people upgrading to read through and stay on top of.) A second advantage is that releases provide a place to say that all work on something must be completed and has been. For example, all packages have been rebuilt with your new C compiler, so that you know everything works, and everything is linked to only the latest libraries you provide. You probably don't want to rebuild all packages with the new C compiler the moment it lands in your rolling development version, but you do want all packages to get rebuilt eventually. A release provides a natural 'eventually' point in a way that rolling updates don't have. Since a release in preparation becomes more and more frozen over time, it's easier to test and then to be sure that problems have been fixed. Constant changes don't necessarily lead to constant bugs, but they do lead to constantly out of date testing results. This is especially relevant for testing the distribution as a whole, such as installing it from scratch, and any testing that has to be done by hand, since people aren't going to do that continually (unless you pay them, and it's expensive). Similarly, releases provide a natural point to make (and force) decisions about whether something is stable enough or ready enough to be shipped to normal people, while also allowing enough time for problems to be fixed and things to be stabilized before you have to make that decision. This probably simplifies the overall package ecology, because you don't get as many situations where version X+1 is in the 'test' rolling version and other packages are starting to depend on it, but it can't be pushed to the stable rolling version and so it's blocking other package updates that are themselves stable. If you decide that version X+1 is not ready to be shipped as part of the next release, it's pulled from the in-preparation package set and all other packages have to (re-)build against the old version. And your package management system will automatically tell you about all of them through dependencies. On a political level, this means that your distribution doesn't have to deal with constant arguments over whether X or Y is ready. All of those arguments can be deferred for much of the release cycle, because they're only really important when the package set is stabilizing before release. Similarly, you're not completely committed to significant transitions until the release is freezing; before then, you can at least theoretically change your mind. (In practice you've probably already landed a lot of preparatory packaging, tooling, and documentation work, and you may have abandoned old packages that you didn't expect to ship in the new release. It's not like there's a magic switch to throw that would restore full Python 2 support just like that in, say, Ubuntu 20.04.)