It's completely bizzare how distributions with long release cycles (think debian) think they can lock on one version of browser and live with it forever.
Absolutely makes sense for core libraries, makes less sense for server software (bitrotten mysql, anyone?), makes no sense for desktop apps.
Ubuntu desktop LTS is meaningless if it won't update its browser. Why use a desktop OS if the browser is outdated?
I've long argued that the entire Linux mentality of distros and packages is broken, and one of the huge reasons why it'll never be widely adopted in the desktop.
Linking versions of trivial software like photo organizers or music players--or even more important software like browsers--to a specific version of the entire system makes it impossible to ever have a stable, yet reasonably up-to-date system. For example, what if you don't want Unity but do want Firefox 7? Or do want updated indicator applets, but don't want broken wifi because of a driver bug in 11.10? (Personal experience, that one.) Your only option is adding PPAs, hoping there's a .deb, or compiling from source, all of which are beyond an average desktop user. And even if you do that, if you wait long enough the distro will have advanced so far away from your personal setup that upgrading other things will become a nightmare.
Linux should move away from the monolithic distro paradigm and towards a stable, rarely changing core of essentials like compositing, video, wifi, hibernate, etc., with optional highly updatable packages of "smaller" software like Banshee, Firefox, etc. That way you can have the best of both worlds: stable core software that the user never sees, and individually updated smaller software that the user wants to be fresh.
Rolling release isn't quite the same, because you still get frequent updates to "core" software. For example I hear from many Arch users that it's great, but it breaks even more frequently than Ubuntu. (Though I've never personally used Arch.) It seems that Linux today is either ancient, stable, and frozen in a bygone era like Debian Stable, or fresh but frequently broken, like Debian Sid (or Arch). There's no inbetween.
And saying "my system works flawlessly, except that time when I had to Google how to modprobe my temporarily broken wifi, or when I had to boot into rescue mode to edit GRUB" doesn't count. You can't have a flawless system with "except".
I'm suggesting that Linux needs something inbetween rolling release and milestone release. Something that keeps invisible core software essential to basic system functionality like wifi and video on stable milestones, but has smaller user-facing software always up-to-date. I don't know if something like that is possible given the current state of Linux package management. But it's clear to me that both rolling and milestone based distros either 1) break too frequently for mere mortals, or 2) cram unwanted changes down my throat for the sake of just one or two new packages I want, or 3) have user-facing software older than my grandma.
Windows has managed to do it. You can still run Firefox 7 on Windows XP, and I can guarantee that upgrading to FF7 on XP won't suddenly change your desktop to a shoddy OSX clone behind your back or break your wifi.
One use case I can think of where this makes sense - Big companies have policies where you have to get every version of an open source software approved by legal because the license might have changed. Having a frozen set of versions makes software an easy sell for such customers.
I'm happy with Firefox 3.5.16 in Debian stable. I have no problem visiting websites, and I don't have to sweat Vimperator breaking because of a browser rev.
I think that caring about the latest browser version is the domain of webdevs and teenagers.
I don't think Ubuntu has as strict policy on releasing feature-updates as Debian. So I wouldn't rule out that browser would be kept up to date. And of course you have always the ability to use some other binaries than those provided by Canonical.
Once, in Ubuntu 9.04, the cherrypy3 package was completely broken due to the upgrade to Python 2.6 [1]. (The version they were shipping at the time was 3.0.2, which was released in 2007.) Literally nothing worked. At all.
There was a new version of CherryPy that was Python 2.6 compatible, but they didn't upgrade to it. Instead, they had to go through the Stable Release Upgrade process, which took two months. Instead of upgrading the package from a version released in freaking 2007, they just added a patch that fixed the specific issue. And this was for software that was completely and totally broken. The chances that they would upgrade software that still worked fine but added some cool new features is just about zero.
As dimmuborgir already pointed out, they do upgrade Firefox. It's the exception of the rule and my impression is that there was much gnashing of teeth when Mozilla's update policy forced Canonical to start doing this.
Makes sense to me, but do they have any/many corporate customers? I'd imagine the expense of maintaining a distro branch over time grows super-linearly.
As a side note, it's interesting to point out that Red Hat has long held that they're not really interested in the desktop market [1], so it's good to see a Linux distro make a play in the corporate desktop space.
No, but that's the point. The 3 year product support cycle scares away corporate customers. Most CIOs don't want to be forced to do a hardware refresh before it's absolutely necessary.
I assume the majority of the corporate desktop users are developers who also use Ubuntu as a server platform. E.g. me.
So basically they are extending their "server" support to desktops too. I always found it funny that it was tiered like that, considering that they use the same packages.
I don't know too much about how the Canonical maintenance process works, but I imagine for all the server packages maintainers have to backport all new security and bug patches that come out to the package versions in the LTS releases.
It would follow that doing this for all the desktop packages would be extra work.
