The diary of a dedicated Ubuntu user that lucked into his dream job working on the Ubuntu team.

Wednesday, November 24, 2010

Ubuntu is *not* moving to a rolling release

So, I just got asked to provide a statement about whether Ubuntu is moving to a rolling release. The statement I provided was:

"Ubuntu is not changing to a rolling release. We are confident that our customers, partners, and the FLOSS ecosystem are well served by our current release cadence. What the article was probably referring to was the possibility of making it easier for developers to use cutting edge versions of certain software packages on Ubuntu.This is a wide-ranging project that we will continue to pursue through our normal planning processes."

The reason that I was asked to comment on this was that an article appeared this morning that built off of some comments that Mark made regarding daily builds. The article went on to make some reasonable conjecture about possible implications. Links to this article were then labeled things like "Ubuntu Moves to Rolling Releases!"

I do like the idea of making it easier for developer and enthusiasts to use daily builds of software that they really care about, and maybe even have them discover this capability through the software center. Currently you have to find PPAs or maybe activate backports to do this. But having a stable release with a six month cadence plus the option to stay cutting edge on certain packags (at your own risk) is not really a rolling release.

15 comments:

Rick:Reading through the conjecture that this statement produced across the internet, I have to wonder if there is actually merit to exploring a modification to the cadence.

Switching to an 18 month (eg LTS) cadence for release could be beneficial to the ecosystem.1) It would help prevent a lot of the scrambling that developers are forced to do to make their software work on every different Ubuntu release.2) It could help decrease fragmentation.3) Developers could be freer to work on longer projects rather than rushing fragile code out the door.4) Security workload could be decreased. Rather than having to do security patches for a vulnerability in 4 releases, now it's just 2.

This wouldn't mean that the 6 month cadence had to go away, but it would allow for two major checkpoints (at 6 and 12 months) that a set of goals could be evaluated without needing to push out all of the efforts for another release.

For examples sake, that could mean that once prickley piranha was release in 2012, the repositories for questionable quokka would stay in development for 18 months, just encountering freezes at 6 and 12.

As I understand, the server team already treats the releases between LTS as 'technology preview', so this could be in line with what some teams are looking for.

I totally agree, PPAs should be easier to find, use and install directly from the software center. the concept could be similar to yppa:http://www.webupd8.org/2010/11/y-ppa-manager-easily-search-add-remove.html

launchpad ppas are pretty safe so why the hesitation of integrating them with software center? I mean is like if you guys didnt trust your own platform.

One approach that might also work would be separating the "core OS" and "applications" from each other, having core OS follow a six month (or slower) cadence but allowing more freedom in the applications space.

This is interesting. 90% of Internet users would like to have a semi-rolling release model, only that they don't know it. Semi-rolling is: when a new Firefox comes out, you have it; when a new X server, kernel or something like that comes out, you must wait to the next stable release. Why don't you just do that, and decide case by case what deserves to be updated and what must wait until next release?