The promise that a certain version of Ubuntu will be supported for a specific number of mounths does not necessarily mean a promise to fix all bugs or even a promise to fix any bugs.
Note this quote from the Ubuntu web page for Desktop business users.
Stay up-to-date with free and regular updates and upgrades
See the graph called Ubuntu for Desktop Release Cycle. Notice that the next two LTS releases will get 2 years support for Hardware and Maintenance Updates and a further 3 year support for Maintenance Updates. That may include bug fixes but it does not imply a promise to fix all bugs during that period.
It is similar for the server LTS versions as this page for Ubuntu server business users shows. The main difference is that Hardware and Maintenance Updates extend for the full 5 year period.
As the link in your question to a bug report shows, it is often very difficult to determine exactly what package is causing the problem and we can also see that a lot of effort by volunteers is put into sorting out bug reports to determine which should have priority and who is responsible for fixing it.
When I read this page on helping with bugs I see that the Ubuntu development community is reacting to bug reports in a very orderly way.
You need to also consider that Ubuntu is a distribution. It takes software components from other parts of the Linux community and brings them together. What if the bug is in the Linux kernel, or Debian, or Gnome or some other component that Ubuntu does not have responsibility for.
The bug report has to be pushed to those responsible for maintaining and developing the package that has the bug. And it is then up to those people.
Sometimes the Ubuntu people can provide the fix as well as the bug report. It is important that the fix gets pushed upstream (as it is called) then all in the Linux community can benefit and not just us Ubuntu users. It takes time for the fix to go upstream, be accepted by those upstream maintainers, and come back downstream to be patched into Ubuntu.
I am not surprised that sometimes a decision is made to fix the problem in the next to be released version of Ubuntu rather than fix it in a version that is soon to be superseded. Especially if that next version is to be an LTS version with 5 year support.
You say that that particular bug is being fixed in Precise Pangolin but not in Oneiric Ocelot. But Precise Pangolin 12.04 has been under test for almost six months. By putting the fix into Precise, the fix gets tested.
This is better than putting it into Oneiric for users expecting a stable release to test it out, do you not think?
Fixing the past can wait. Get the future "precise" at the start. That is what is important, in my opinion.
Think of apt-get upgrade
as a safe upgrade while testing candidate releases. You should use it normally for (mostly) daily upgrade process to keep your packages up to date without* breaking your system. The upgrade option is used only to update the packages already installed on your machine to a newer version.
apt-get dist-upgrade
will not only upgrade all of the currently installed packages on your system but also handle the dependency changes for new versions of packages. It intelligently** will remove obsolete packages from your system and install any further necessary. During beta use this option with caution. Normally this function needed for upgrading from one distribution release to another.
* Without breaking is a big statement, remember, this is alphas or betas we are talking about.
** Intelligently is definition but because all is beta extra caution should be taken.
Precautions to take while upgrading a pre-release
- Upgrade only using the terminal, at least you will know exactly what is going to happen before pressing
Y
and letting apt do changes to your system.
- When running a
apt-get dist-upgrade
is needed (new kernel, major change on system packages, etc) make sure that you first run apt-get dist-upgrade -s
to simulate and please read all the changes the upgrade will apply. If you see any weird changes (_I remember killing my system after a dist-upgrade asked me to remove some necessary system packages and the Ubuntu Software Center while 12.04 was in alpha 1) abort it and update you packages again in a few days.
- Do not use the update manager while updating a pre-release. Make sure that you can read everything that is going to happen to your system before pressing
Y
.
- Don't be too eager to update! Don't do it out of speed, this is a sensible process during a pre-release. Use caution and some patience when testing it.
When should you use a upgrade compared with a dist-upgrade?
Use a dist-upgrade when you know the pre-release just went from alpha to beta or the next scheduled step or in the "Wont update these packages" list during a apt-get upgrade
there are new kernels and other major packages, be extra cautious of the list of packages that will be removed. If there is anything there that you are not sure, or that you think it might break your system abort it after the simulation and get your self informed via the forums or on the IRC channels before applying the changes.
If you need further help during the update period or just a quick chat to point you in the right direction during an pre-release system read the informationins this post
Don't be hasty and be prepared all times, a backup or 2 are never too much to ask when testing.
Best Answer
Because there's always a development version. As soon as the development version is frozen, people start work on the next version which then becomes the development version. It just ticks over like that every six months. "+1" simply refers to the "next release".
"+1" is also used to refer to the +2 (etc) when the name isn't know, like "Trusty+1" to refer to 14.10.
But the stable release is released. By all intents, it's done. It's perfect. The only exceptions to this rule are:
What you're describing is a rolling release where stable and development are practically the same thing. That's not how Ubuntu works.
Anything. Everything.
With the exception of the list above, nothing changes in a stable release. The idea is to keep a stable release stable and that's done by modifying it as little as possible.