Phoronix: Ubuntu To Pull In New Versions Of Firefox
Ubuntu's longstanding policy of not pulling in new major versions of packages into their stable repositories is facing a slight change. Canonical along with the Ubuntu development community have been making it easier to deploy Mozilla Firefox web-browser updates into existing Ubuntu releases...
Can this extend to newer versions of other non-critical packages as well, e.g. Pidgin?
This policy is specific to Firefox at the moment (and also Chromium), due to the way their support models work. There is no need to apply the same policy to other software that doesn't present the same maintenance challenges.
Originally Posted by anbog
Does this mean that Lucid will upgrade to Firefox 4.0 when it is released, or wait until Mozilla drops support for the 3.6.x series?
Lucid will get Firefox 4.0 as 3.6.x approaches EOL
A short list of packages that are reasonably popular, have a similar maintenance model to Firefox (i.e., upstream "productizes" it), and are not going to prevent you from getting to a working graphical desktop if the upgrade breaks:
*Sun Java (or OpenJDK)
*Thunderbird and Sunbird
*Second Life or Snowglobe
As an added bonus, all of the above have an excellent history of backwards compatibility, if applicable. For instance, every single program that runs on Java 6 will run on Java 7, as a matter of strict operational policy for the Java Community Process. There is virtually zero risk to pushing a new stable version of Java to the repositories. Contrast this with Mono, which breaks things sometimes in favor of API cleanliness -- so we wouldn't as easily be able to ship major updates to MonoDevelop or the Mono core without updating all Mono apps, for example.
Also, these apps generally have self-contained changes that do not require invasive dependency upgrading, except in very rare situations:
*And a bunch of others I can't think of off the top of my head...
If Canonical knows what's good for them, they will allow the Firefox example to set an operational precedent, and consider some of these other apps as candidates for major version SRUs. If they take the conservative route, though, they will continue to waste everyone's time and defeat the value of the LTS release.
On the topic of the LTS releases, I actually think the most valuable place to bring new major productized application releases is into the LTS. For people who only install LTS releases (enterprises), the datedness of the Ubuntu 8.04 application stack by the time Lucid was ready made 8.04 virtually useless. But there was absolutely nothing preventing the venerable old Hardy 2.6.24 kernel and aging userspace stack from running OpenOffice.org 3.1, or Firefox 3.6.
The folks who maintain backwards compatibility with old userspaces between releases spanning several years deserve a lot of credit, because they essentially make it possible for users who require stability to also benefit from new feature developments in applications. And let's face it, features in apps are where the real value is for most users, not in performance optimizations like KSM and CFQ.
An Ubuntu LTS release that keeps its top-of-the-line apps updated is very competitive with Windows. After all, folks running Windows XP in 2009 are using a decade-old kernel and running brand new software on top of it. Imagine if they had to stick with Office 2000 and the rest of the 2001-era Microsoft app stack until Vista came out. That degree of stagnation would have put Microsoft out of business -- and yet we have no problem with that on Linux? C'mon.
Yes, that would be rather cool. We could call it a rolling release schedule.
I also thought it was a cool idea to not upgrade every 6 months and always have the latest package version, which is why I switched to sidux for my main install.
For the most part, it works as I want, although Debian sid is a bit behind on some key packages (WINE, iceweasel).