In defense of Fedora’s release cycle

Earlier this week, Thorsten Leemhuis published a thoughtful post about what he’d change if he magically became the supreme leader of Fedora. In that post and subsequent commentary on Mastodon and Fedora Discussion, he talked about changing Fedora’s release cycle. Since the Fedora Linux release process is my job, I figured I should explain why I disagree.

Integration projects are different

If you haven’t read the post, you should. But here’s the short version: Fedora Linux uses a release model rooted in the 1990s and should move to a “modern” model. Thorsten suggests a one-month cadence for those who want the latest versions and a one-year “steady” release. Such a model has worked well for Firefox, he argues, and so it should work for Fedora.

The key reason I think this is wrong is because Firefox is a development project whereas Fedora is an integration project. Integration projects don’t write a lot of code, they take the work of others and turn it into a coherent whole. This is a fundamentally different kind of work and it takes longer by necessity.

You can’t reliably integrate disparate pieces when they’re in constant motion. That’s why we have freezes leading up to the beta and final releases — they give the QA team time to test against a stationary target. It takes time to run through all of the test cases that make Fedora Linux a reliable operating system. So the choice becomes reducing the pre-release testing or spending a significant portion of the cycle in a freeze, which limits the the usefulness of the one-month cycle.

You can solve some of this with automated testing. And the QA does do a lot of automated testing. But those tests still take time, and there are a lot of interrelated parts in a Linux distribution.

Six months isn’t magic

There’s nothing objectively correct about a six month release cycle. It’s mostly because that’s how you get two releases a year. If the calendar had 10 months, the release cycle would be five. But there is a lower bound where you’ve become a de facto rolling release, even if you still have discrete releases. I don’t know where exactly that boundary is, but I suspect that one month is at or just beyond it.

Similarly, there’s an upper limit where you’re now a slow, plodding project. Again, I can’t say where the line is. Six months may be uncomfortably close to it, but I suspect it’s closer to a year. And, of course, it depends on the nature of the specific project.

So there’s no particular reason Fedora Linux couldn’t move to a shorter release cycle. Five months is totally doable. Four is possible. Three would require a tremendous amount of work before it could be considered. But what’s the benefit of going to a shorter cycle? Does five months instead of six make a meaningful difference? At least with six months, you know there’s a release targeted for April and October. Predictability is nice.

Solving the actual problem

The bigger issue, though, is that I don’t think people actually want this. Yes, you might want your web browser and other applications to update frequently. But that doesn’t mean you want your compiler or Python interpreter or C libraries to update frequently. Most people will avoid this in favor of the “steady” stream. This eliminates the intended benefit to upstream projects.

The people who do want everything to update quickly use a rolling release distribution, something that Thorsten explicitly says his proposal is not.

Fundamentally, the proposal looks at the problem the wrong way. The problem isn’t that a six month cycle is too long. The problem is that application delivery is coupled to operating system delivery. Most people want the latest versions of the applications they care about and for everything else to remain unchanged. The challenge, of course, is that not everyone draws that distinction in the same way.

We unsuccessfully tried to solve this with Modularity. Flatpak, at least for graphical applications, offers another attempt to solve this problem.

Historically, the system and application layers have been distributed together. Figuring out how to decouple these (including how to draw the line between them) is the interesting work. And it provides real value to the end users.

3 thoughts on “In defense of Fedora’s release cycle

  1. “So there’s no particular reason Fedora Linux couldn’t move to a shorter release cycle.”

    If I remember right, Fedora went with a six month release cycle because that’s what GNOME had – so Fedora wanted to trail GNOME by a bit so it could pick up the latest GNOME and have a little time to integrate and test it, etc.

    So a five month or shorter cycle would blow up the cadence of GNOME -> Fedora.

    I find the idea of a shorter release cycle for Fedora lightly horrifying. For work I use a RHEL* system and a macOS system, and I have Fedora on an older 12″ ThinkPad that it runs just great on. Because I don’t use it as my daily driver I spend more time that I’d like *already* running updates every time I pick it up. I wouldn’t want to add full-on system upgrades to the mix.

    *RHEL and not Fedora because there’s some required software that is certified for RHEL and not for Fedora and our IT folks (fairly enough) don’t want to worry about the times when it might not work perfectly…

  2. “So a five month or shorter cycle would blow up the cadence of GNOME -> Fedora. ”

    Yes it would. And it would also put us out of sync with Python, who recently moved to a predictable schedule that fits nicely with ours. We’ve tried (unsuccessfully) to get KDE to move from a four month schedule to a six month schedule for the same reason.

    That said, we could certainly decide “well the rest of our upstreams release at unpredictable or unaligned times, so we might as well break the sync with GNOME, too.”

  3. The most important reason to release an update is in my opinion for security reasons. The rest are more related to newer versions of existing software and to a lesser degree, new features/functionality.

    Security updates are important to get out as soon as possible, whereas new features/functionality are something that I personally feel should be held back until developers feel reasonably comfortable with their current state – otherwise these new features/updates run the risk of introducing bugs/instability.

    I think this is a healthy approach that would benefit the majority of users who need the software to simply work as intended and are less concerned with added functionality. I have a gut feeling that hose who are longing for changes and added features are in the minority – just my hunch though.

Leave a Reply

Your email address will not be published. Required fields are marked *