There was a discussion on the Fedora devel list late last year about moving to a more rolling release model, and I have seen people continue to suggest this in various places since then, so I thought I would write up my thoughts on rolling releases and how they can/could apply to Fedora.
Note that I am speaking only for myself here, not my employer, FESCo or anyone else.
First, lets talk terminology. What is a “rolling release”? In reference to Linux distributions, it’s where you provide a continual stream of updates for your distro and all work is done in one branch (there’s no seperate point releases, there’s only the distro). (See:Â http://en.wikipedia.org/wiki/Rolling_release for much more discussion and terms, but I think that the above boils it down some).
Now a bit of Fedora background: Fedora has a devel/master branch, called (for historical reasons) rawhide. Is rawhide a rolling release? I would argue that it is. In addition currently Fedora has at various times 2-3 more branches/releases being maintained. Updates to these are guided by the Updates policy:Â http://fedoraproject.org/wiki/Updates_Policy. These releases are on a 6month (roughly) cycle. A new branch/release is branched off rawhide, then stablized and released. Old releases are retired 1 month after 2 releases happen. These are not at all rolling releases by the above definition.
So, lets take some updates examples and see how things work now in Fedora vs what they would look like in a rolling distro:
You have foo-1.0-1 installed and foo-1.1-1 comes out. It’s minor bug fixes, possibly docs and translation updates.
- On supported stable Fedora releases: You would possibly get this update if the maintainer felt the bug fixes were worth bothering with.
- On a rolling release/rawhide: You would get this update and not really notice it unless you were hit by a bug in this package or needed the docs or was heavily involved with it.
You have foo-1.0-1 installed and foo-2.0-1 comes out. It’s a major new version. The UI changes along with lots of other things.
- On supported stable Fedora releases: You shouldn’t get this update if at all possible, the exceptions might be if upstream stopped supporting foo-1.0 at all and this fixed security updates that couldn’t otherwise be fixed any other way. If you are a happy foo-1.0 user, I would argue that you don’t want foo-2.0 to suddenly appear and cause you to have to learn how to use it. In a timed release model like Fedora currently uses, you would get foo-2.0 at the next Fedora release, when you have time and desire to sit down and learn all the new changes. You can schedule it on your timeline, not when it appears in the repos.
- On a rolling release/rawhide: You get this update quickly, and must deal with learning the new UI right then. If you have important work in foo-1.0 and are on a deadline, you don’t have much choice when you have to learn 2.0.
You have libfoo-1.0-1 and libfoo-2.0-1 comes out. This is a major new library version, the ABI/API changes. All applications using this must rebuild and probibly get patched to work with the new version.
- On a supported stable Fedora release, you won’t see this update. You will get it at the next Fedora release. This gives you time to port your applications to the new ABI/API, and you can sit down and fix things when you upgrade to the next Fedora release.
- On a rolling release/rawhide: You get this update pretty quickly. The majority of things that need rebuilding are done, but stragglers are sometimes left broken by the upgrade. If you use one of them you are out of luck, or must spend time getting them working as soon as the bundle of packages land in the main repo. There’s some ways around this of course, like compat packages for things, but in general if your application is very slow moving there may be a lag in support.
You have rpm-N and new rpm-N+1 is released with a new package format/compression/payload. (Or you move all / dirs to /usr, or…)
- On a supported stable Fedora release, you never see this update. It’s only on the next Fedora release.
- On rawhide/rolling distro: You announce this in advance and try and get people to make sure they upgrade to the new version, you add docs about the error the old version prints when it can’t deal with the new version. You have a flag day to cut over and anyone who missed the memo has to go figure it out before they can get more updates.
(I could go on with the examples, but I could do that all day. Feel free to suggest other scenerios in comments 😉
As an aside there’s some notable exceptions to the Fedora updates policy worth mentioning:
- The Linux kernel. Currently Fedora keeps pretty close to the most recent upstream stable kernel version for _ALL_ Fedora stable releases. This occasionally causes problems for folks as new bugs make a machine that was working fine not boot, or have issues. There are a number of reasons for this: First, backporting security and bugfixes to old kernel versions is a vast amount of work. Fedora has a crack ninja team of kernel maintainers, but they are a small team. Backporting new hardware enablement would also be very difficult, and new hardware is always appearing. Not allowing new kernels on old releases would result in needing to upgrade to support new hardware, which isn’t very nice. Additionally, kernel is a special package in Fedora, in that it’s one of the few you can install multiples of. So, even in the event of some new bug, you can boot the older working kernel and debug the new problem.
- KDE. KDE upstream unfortunately has releases that are not at all aligned with Fedora. This is of course their choice, but it makes things hard for us. Additionally, older major versions aren’t supported, so, when Fedora N ships KDE 4.x at release time and 4.x+1 comes out in a month, we really have no choice but to update to that as again backporting manpower isn’t there.
So, do I hate rolling releases and want nothing to do with them? No. I think rolling releases are quite valuable, and a good fit for a small group of folks. You may like/want/use rolling releases if:
- You are a early adopter (You WANT foo-2.0 as soon as it’s announced)
- Love troubleshooting issues (You don’t mind when things break and are happy patching something to be fixed up for a new version, or reporting bugs on a new version of something)
- Are an integrator/software developer. (You want the latest libraries and toolchains to make sure your project builds and works there and takes advantage of the latest cool features)
- You are a distro integrator and enjoy making all the parts of things fit together as soon as your upstreams have released them.
However, if you are anyone else, you probibly don’t want to be using a rolling release. With a timed release, YOU can choose when you have time (+ or – 7 months in Fedoras case) to upgrade to the newest collection of software, relearn new applications and ui’s, rebuild/fix local code to new libraries, etc. With a rolling release, you are at the mercy of the upstream projects and your distro as to when you have to accept and adjust to a change.
So, if rawhide is a rolling release and some folks want Fedora to do one, why don’t they just use rawhide? I think there’s a number of reasons for that, many around rawhide being too raw for day to day use. However, I have been working on a number of ideas to improve day to day usefulness of rawhide, as well as using it myself day to day. Look for those ideas soon. Possibly we can address some of those concerns and get more folks using rawhide day to day and have the best of both rolling releases and timed stable releases.
