In Gazette issue 4 I talked about the focus on stability when updating packages in active releases.
This is a requirement and pleases many, yet open source isn’t about one but many different needs, solutions and kinds of people.
Gladly, I have a new joiner in the team, @j.j who put me nose-first onto what almost feels like the opposite topic by recently asking :
“Shouldn’t Ubuntu also be more fresh, maybe provide rolling release updates of new versions?”
Initially I was mostly lost, stuttering “umm, you can already have all that”, but then realized I didn’t understand - which opened my eyes. I realized, while explaining, that there is a whole hierarchy where users can pick whatever suits them best and thereby allow you to find where in the balance of stable vs bleeding edge you would prefer to find yourself in. Let me channel that discussion into a post that might help you, and anyone else out there that are on the other side of the “balancing stability” topic, who want more changes, more often and to be fresh all the time.
Ubuntu Freshness scale
Please pick from our menu of fresh choices based on your own preference
To help you identify where alternative solutions could be placed in this totally non-scientific ranking, I’ve put a self-defined unit called “Freshness Classification Reference” (FCR), which surely is perfect terrain for bikeshedding about details. Please be so kind as to read it like “with some fuzziness in details, in regard to how fresh it is, it’s somewhat comparable to …”
| Solution | Software feature age | Stable vs Fresh balance |
|---|---|---|
| Ubuntu LTS that has entered Legacy Long Term Support | Up to 12 years ago | Extra reliable, proven and you might just not want (or be able) to change but stay supported - Except a few special cases like HWE kernels usually no new features since its release |
| Ubuntu LTS in Expanded Security Maintenance | Up to 10 years ago | Reliable, proven and you might just not want (or be able) to change but stay supported - Except a few special cases like HWE kernels usually no new features since its release |
| An actively supported previous Ubuntu LTS release | Up to 5 years ago | Reliable, proven and working fine - Except a few special cases like HWE kernels usually no new features since its release |
| The latest Ubuntu LTS release once it reached version “.1” | Up to 2 years ago | Reliable, proven and working fine usually having recent enough software to cover even new needs This is a common option used in highly controlled server/production environments. And that time usually is also when automatic LTS to LTS upgrades are enabled to ensure users get a smooth upgrade experience. |
| The latest Ubuntu LTS release | Up to 2 years ago | Working fine usually having recent enough software to cover even new needs. FCR: Debian stable |
| The latest Ubuntu LTS release with proposed enabled | Up to 2 years ago. With earlier update releases (before they are released to everyone soon after) | This is a shameless advertisement to make more people aware of testing of upcoming SRU changes in advance to help them from outages and help everyone by providing verification input. |
| The latest Ubuntu release | Up to ½ year (semi-rolling release) | Contains software from the last half-year development cycle, with coordinated pieces to work well, but with quite recent software release, covering even very new needs. This is a common option for Ubuntu Desktop users that want fresh features. FCR: NixOS, Fedora |
All of the releases above are active releases, they get regular targeted bug and security fixes via the SRU and security update processes. Versions below receive updates and fixes constantly while being in development, so you might say they get “rolling updates”.
| Solution | Software feature age | Stable vs Fresh balance |
|---|---|---|
The ongoing Ubuntu devel release |
Daily updates from the development team (rolling release) | Contains rolling updates of the newest software as it comes out of completing proposed migration as integration test, so this is the bleeding edge version of the latest and greatest updates. To start using it, adjust your current apt sources config to point to the current devel release. This is also available by starting from the new monthly snapshots. At the end of a development cycle, there’s a “feature freeze” period in which it is release-tested by various teams and the community. Then this “devel” version becomes a new release! This is a common option for Ubuntu developers who use devel on their systems to ride on the bleeding edge of updates, and to find rough edges to fix before they hit other users. If you’re interested in having the latest software, and want to solve problems before others have to, you’re very welcome to use “devel” too! To stay with a rolling release after a devel version was released, you have to hop to the next in-development version as soon as the next release is named and the archive has been opened for development (you can decide to do that at any time). To stay on a rolling release, there is an alternative in the form of Rolling Rhino. That isn’t directly from Ubuntu, but a community project based on the Ubuntu devel which will automatically keep you on the devel release in addition to some custom e.g. desktop choices. FCR: Debian sid/unstable, Archlinux, Gentoo, NixOS unstable, Fedora Rawhide |
The ongoing Ubuntu devel release with the -proposed pocket enabled |
Daily updates as fresh as developers push them (integration tests have not yet passed) | Even more bleeding edge, software that has completed build time tests (if any) but not yet integration tested via proposed migration. This is not recommended, but an option worth mentioning. You would run the same version as our integration testing is running! FCR: Archlinux Testing, Gentoo ~keyworded |
So do we have a “rolling release”, well yes and no - we have nothing that we call that way. But strictly speaking, as long as you stay on the current devel it very much behaves like one. And from here it is up to you and your choice between the above to pick what you prefer.
Why don’t more people know about “devel” then?
After our discussion Jonas rightfully asked:
“Well if Ubuntu allows all that already, that is great - but maybe we should market it better: For example we could start by having a clear download button to get the ongoing devel release.”
And yeah, given how the discussion above went, I must admit that it may be an awareness problem and we need to communicate it better. Not everybody knows about devel being already a rolling release and something like an official download button might make this clear to those that do not already know where to find daily ISOs and cloud-images. Since the great “rolling rhino” name is already taken, how about “devel dolphin” or “fresh fox”? Which then would be a name that would stay, just as Debian unstable is always called sid?
Could look like (sorry, this is just a mockup):
In the subsequent discussion I realized there could be way more, albeit unsure if it would be worth the investment: A true name/alias to put in apt sources which will keep rolling forever, so no more need for adjusting to the next release name. Since it would never become released, it would not have -security/-backports/-updates pockets, so the config would be quite concise. The imaginary “fresh fox” rolling release would look nice, easy and always be “fresh”:
Types: deb
URIs: http://archive.ubuntu.com/ubuntu
Suites: fresh
Components: main universe restricted multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
I’m in love with this by the wording alone already. Yet I have to admit I haven’t thought this one through and I’m already aware of some technical hurdles. I’m sure there are more reasons blocking this from being as easy as I’d wish it would be. But let me dream how it should be to have a true rolling release - also to get opinions and preferences from you on the topic!
Was that explanation all you needed?
Does the above already cover all your need for freshness - did you just need to know and are happy now picking the release that is the right one for you?
Or should we hereby start a new discussion to hear your thoughts on it? Some suggestions will be lovely but impossibly complex, others might be easy but not useful to anyone - but in between there could be a sweet spot that might be doable and provide what a substantial set of users would want.
Disclaimer: This is me and Jonas discussing and brainstorming about an interesting topic, not a commitment of anyone to anything. I’m curious about interest and opinions on this and that can only come up once I spell it out. I am sharing this to gauge interest and gather opinions, which can only happen once the idea is clearly articulated.
P.S. until next time …
I realize that I regularly drift into philosophy and policy topics in my posts. That could be an artifact of generally being rather involved as a member of all the lovely abbreviation teams like MIR, AA and DMB. Which are often not explained too well and therefore in recent times I’m even more involved via uniting and updating the various documentation about how ubuntu is made to explain such processes like Main inclusion review (MIR). And yes, we haven’t yet moved together all the places talking about proposed migration and similar testing steps, but these are scheduled to be done in the next couple of weeks.
But what I wanted to say, I’ll try to keep the balance and have something more technical again next time …