Let's Discuss Interim Releases (and a Rolling Release)

[Marc Deslauriers]

On 13-02-28 10:31 AM, Rick Spencer wrote:
> To succeed at this we will need both velocity and agility. Therefore, I
> am starting a discussion about dropping non-LTS releases and move to a
> rolling release plus LTS releases right now.

YES! :P

> 
> = Role of the LTS Releases =
> Many users prefer their OS does not change very often. We have a great
> system in place for these users. Every 2 years Ubuntu release an LTS and
> users can ride that LTS for the whole support period. Since the LTS
> comes out every 2 years, they can set a 2 year cadence of updates if
> they want to stay "up to date" with LTS releases. I think this 2 year
> cadence works out very well for these users. So, this proposal maintains
> those LTS releases as anchors for those users.
> 
> = Role of the Interim Releases =
> But what about the 3 releases we do every six months in between (what I
> call the "interim releases")? Who are they for? Why do we invest so much
> in supporting multiple interim releases at a time?

I completely agree with dropping the interim releases. I have been
recommending that everyone use LTS releases for a long time now, as they
are usually of much higher quality and stability than the interim releases.

> * Due to Daily Quality efforts, the development release is now usable
> every day, so enthusiasts and community members don’t have to wait for a
> stable release to get the latest software and can participate more fully
> in the development of Ubuntu

Yes, Raring has been quite a delight to use and update every day.

> 
> More clearly, I think we should:
> * Stop making interim releases.
> * Keep doing daily quality and keep improving our daily quality.
> * Take a monthly snapshot of the development release, which we support
> only until the next snapshot
> 
> That means users could choose:
> * The LTS release
> * The rolling release updated daily or as frequently as desired
> * The rolling release updated at least monthly

I like the monthly snapshot idea. It allows us to set goals, promote new
features, and allows technical enthusiasts to use the development
release without having the massive package churn every single day. This
also isolates them from bad uploads in the rare cases where they may occur.

> 
> == For Users ==
> Users who prefer the LTS releases will be unaffected by this change, at
> least directly. For users who prefer more up to date software, the
> rolling release will truly provide the latest and greatest software that
> they are looking for, but without the 6 month wait for a new release.
> Developers won’t be under pressure to rush a feature in before the
> release deadline, so users will be receiving more complete software when
> they do get updates.
> 
> == For Community ==
> The community will benefit from the simplified model. They will be able
> to recommend either the LTS or the rolling release, and the users of
> each will be clear. People who need to provide support may find their
> lives dramatically simplified, because on any one day, there will
> essentially be 2 releases with clearly differentiated user bases instead
> of their user base being distributed across a minimum of 3 supported
> releases. For example, on any one day, an ISV typically would only have
> to worry about the LTS releases and the current rolling release, instead
> of 11.10, 12.04, 12.10 and the current development releases, Raring.
> 
> == For Core/MOTU Developers ==
> For the people who are actually making Ubuntu (the people on this thread
> I hope) there are some clear wins as well.
> 
> 1. Only 2 releases to support, the LTS and the rolling releases. That
> means fewer SRUs to worry about, and only for LTS releases. More time
> and attention to focus on what we are building instead of what we had built.
> 2. Features land when they are ready, not earlier or later.
> 3. No one will get stuck supporting "old" software that is not part of
> an LTS release.

I think this will greatly simplify handling bugs. If there's a bug in an
LTS release, it's worthwhile to get it fixed, as that's what most of our
users will be using. If there's a bug in the development release, it's
easy to fix it or to move to a newer upstream that has fixed it. I've
seen bugs and SRUs go untested for a long time because they are in an
older interim release, which nobody is actually using anymore.

Getting rid of the interim releases will reduce some of our security
update maintenance burden and will allow us to concentrate on getting
more security issues fixed and increase the time available for getting
more proactive security measures in place.


I think this proposal makes complete sense, and I am all for it.

Marc.