4

Less than a month ago (in October 2013), there was a stable release (Saucy) and now there is one in active development immediately, why is that? Shouldn't development focus on the stable release or both branch/releases will provide the same amount of fixes? What will change in the new development release that can't be imported from the current stable release?

I've seen a couple of questions, but they ask how to move from development to stable, not within the scope. I'd like an answer, like this one Will the alpha/beta ISO become official after Release?

Community
  • 1
Braiam
  • 67,791
  • 32
  • 179
  • 269

2 Answers2

4

Less than a month ago, there was a stable release (Saucy) and right now there is one in active development immediately, why is that?

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.

Shouldn't development focus on the stable release or both branch/releases will provide the same amount of fixes?

But the stable release is released. By all intents, it's done. It's perfect. The only exceptions to this rule are:

  • Security updates. This is the major cause for pulling back fixes.
  • Browser updates. These used to limited to backporting security fixes but it was deemed more beneficial to pull the entire browser forward.
  • Other Stable Release Upgrades where the significance of the fix is deemed worthwhile (and without damage).
  • LTS Hardware Enablement stacks. These are bundles of kernels, drivers and X builds that are brought up to the latest stable versions each release so that LTS users can stay mildly updated without changing the rest of the system. This is important given the speed of graphics improvements (and new hardware) these days.

What you're describing is a rolling release where stable and development are practically the same thing. That's not how Ubuntu works.

What will change in the new development release that can't be imported from the current stable release?

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.

Community
  • 1
Oli
  • 293,335
3

"Why is that?"

There's a clear difference between adding new features and fixing bugs. The first is "development" and the second applies to a "stable" release. The stable release wouldn't be very stable if all the development happening on e.g. Ubuntu Touch and Mir landed on users' installed systems.

That's why, once an Ubuntu version is released as "stable", it doesn't get many new features, instead focusing on fixing bugs on the existing packages without necessarily upgrading them to entirely new versions.

All new development happens in the "development" release, which users are of course free to try, with the warning that bleeding-edge software may appear at any time and possibly break expectations on how the system would behave.

Shouldn't development focus on the stable release

Quite the contrary, see explanation above.

or both branch/releases will provide the same amount of fixes?

A stable release will get only fixes, whereas a development release will get both fixes and new versions/features.

See the procedure for accepting a Stable Release Update into the stable release, you will see that a requirement is to have a bug fixed in the development series first, before requesting it be applied to the stable release. Also read the "Why" section for an expanded view of the explanation I gave.

roadmr
  • 34,222
  • 9
  • 81
  • 93