Given that you can use Ubuntu as a rolling release since at least 2014 this way (i think it was even introduced in 2012) but nobody cared or noticed, makes me wonder if we should all stop writing blog posts and release notes and instead make youtube videos to get actual attention to features … 
4 Likes
Well, there’s a good reason we tried to get people to move over here to discourse and away from dusty, crusty mailing lists which are painful for normals to use. It totally makes sense for us to engage with new users in the way others do. Be that short clips of video, or posts on discourse, I’m up for hearing how to improve the messaging.
2 Likes
Well I also question, what makes this different from like an LTS release with backports?
there wont be clean removals of older stuff so package zombies will pile up on your disk over time (transitions the update-manager normally cares for i.e. if a package is removed from the ubuntu-desktop task nothing will remove it from your disk unless you do it manually (make sure to run “apt autoremove” regulary in such a rhino))…
you might also hit massive breakage if a bigger ABI transition happens and only chunks of packages move forward … this will typically happen right after an LTS release when a new cycle starts and the archive gets a bit shaky all over.
that’s simply the price you pay for constantly rolling on top of the development release.
3 Likes
https://ubuntu.com/server/docs/upgrade-introduction
sudo do-release-upgrade
Upgrading to a development release of Ubuntu is available using the
-dflag.
Sorry to bump an old thread but what’s the difference between rolling rhino and just using the -d flag?
I’ve been meaning to ask this for ages as there’s been talk over the years of manually adding devel to sources.list and recently wimpys rolling-rhino but i never see anyone mention the -d flag?
1 Like
you could translate the name do-release-update as switch distros and -d simply switches you to the current development distro release, you wont be constantly rolling but will end up with the stable release once the cycle is done and will need to manually care for calling do-release-update -d again after a new cycle started.
i’d call it “frogjump rolling” (with manual intervention to do the jump) vs “truely rolling” (no manual intervention needed, apt updates just always roll with the latest)
3 Likes
MS coming out
I use Visual Studio code daily, and many other people as well. I even have Edge, but just to check it out 
It could, but I don’t want it to, I like it to be not be always changing under my feed, there’s only so much change I can deal with, and having a paced and predictable release schedule allows me to plan for it, and so do many organizations that develop with and for Ubuntu.
I believe that using the Rolling Rhyno project, would allow expert users capable of solving problems with using a rolling release to setup Ubuntu as a rolling release.
Something i’m still unclear about is why the advice is given to edit the sources.list instead of using the -d flag?
Is there something i’m missing?
Using do-release-upgrade -d will move your system onto the current testing/development release (currently hirsute) and will continue using it when it becomes stable (unless you again run do-release-upgrade -d), while editing your sources.list file and replacing the release with devel (and then running apt-get dist-upgrade) will make your system always use the latest development release (thus requiring no manual intervention).
1 Like
But then updates spits out verbose errors until development starts again so staying on stable updates and then manually using -d flag when development starts again makes more sense to me?
I obviously have different logic and reasoning? 
1 Like
Like @ogra said, using devel eliminates the need to switch to the next development release every 6 months (thus making is ‘truly rolling’). However, using do-release-upgrade -d will force you to jump to each new devel release manually, thus not making it truly rolling.
1 Like
the -d flag changes your sources.list to the next development release (currently “hirsute”) and will stay there until it is stable, at which point you need to run update-manager again, to get it set to the next devel release.
while changing the distro name to “devel” in sources.list will permanently keep you rolling on the development release without ever requiring to run update-manager again … one is a server side rolling release, the other is manually jumping from stable to devel every time a new cycle starts …
the result of both might be kind of similar, but truely rolling without further manual involvement happens only when using the “devel” name in sources.list
3 Likes
I would also like to see non LTS releases become one rolling release instead. But most importantly, use this rolling release to add new features (try things out) and when mature enough, add to the LTS release. I appreciate that a lot of work goes on under the hood, but users like new features. Those who want a stable OS, carry on using the LTS’s, those who like testing (advancing Ubuntu) go with the rolling release.
How does Rolling Rhino not already fill that role?
https://github.com/wimpysworld/rolling-rhino
The current setup means I can have an almost rolling release by tracking the development release (I’m only a few days short of being on hirsute for six months, with my next bump now a matter of days) which suits me fine… OR I can have rolling (rolling rhino).
I like the six-monthly bump; as it requires a manual kick to start, which I also use to prompt me to check out what I did in the prior six months (for testing purposes) that I can remove given it’s to be a new cycle.
Having only LTS or rolling is less than the 3 options we have now.
3 Likes
Tbh, I’m not too familiar with Rolling Rhino (thanks for the link). What I’m asking is more an official release (just two iso’s). An LTS for most users and a rolling release for testing new stuff. Surely having two iso’s is easier to manage than say 20.04, 20.10, 21.04, 21.10, etc
Daily images are produced almost every day (okay they’re turned off now for hirsute as we’re in RC state, but there are days when more than one is produced too) but the provided link converts the current daily image into rolling rhino meaning we have what you want now; it just contains an extra step you want to eliminate at the cost of the stable non-LTS releases. That’s a pretty high cost in my opinion.
Well lesson learnt , the -d flag didn’t find Impish but editing the sources.list worked perfectly so i’ll do that from now on , thanks all for pointing out that doing via sources is a better option…
Has devel been dropped , I had to change devel in the sources.list too jammy?
jammy is still bootstrapping, i’d assume the devel symlink will only be changed once something workable has landed in the archive …
EDIT: you can watch the ubuntu-devel-announce mailing list where the opening will be officially announced:
here is an example:
2 Likes