Follow Up from "Let's Discuss Interim Releases"

[Thierry Carrez]

Robert Collins wrote:
> One thing I think has been missing from the discussion so far has been
> in reviewing our *definition* of a release. There was some mention of
> defining what Ubuntu is - how big the surface area we maintain, vs app
> developers maintain and deliver /on/.
> 
> I'd like to decompose 'Release' though. Technically, it means a number
> of things today:
> A - an archive that we place a high friction change process on,
> intended to eliminate regressions [the SRU]
> B - a logical name that users can associate with a /large/ bundle of
> changes. One can say 'Unity in Raring is fantastic' only because
> Raring is a thing.
> C - A set of APIs that work well together and which we commit to keep
> working for the duration of the release (except where it is infeasible
> [e.g. due to facebook dropping their support for the server side of an
> API].
> D - A mostly unchanging environment. No surprises.
> [...]

Today, it's also [E] an install media.

> So, here is an alternative approach to solving these four things while
> still integrating upstream changes etc.
> 
> tl;dr version:
>  - Identify a really small set of APIs to support, and set LTS
> timeframes on them. Examples - boot configuration, networking,
> graphics, etc.
>  - For new APIs set timeframes that reflect their maturity (and
> support them for that timeframe).
>  - Support those APIs for that timeframe irrespective of upstream -
> but in selecting them discuss that with upstream.
>  - Use feature flags to decouple 'new code release' from 'new
> behaviour' for the platform itself - Unity, indicators etc.
>  - For key upstream applications (e.g. using data from popcon) make
> sure we allow co-installability of multiple versions. (libreoffice may
> be an example of this).
>  - Move the concept of using 'a release of Ubuntu' to using 'a
> configuration' - LTS is 'keep my behaviour unchanged', interim
> releases are 'give me new features when they are production quality'
> and 'development edition' is 'give me new stuff as soon as it enters
> the archive'.

About LTS mode ('keep my behaviour unchanged') I suspect every n years
you'll have to create another LTS mode. For people who want their
behaviour unchanged but from a reasonably modern starting point. How do
you handle that ?

>  - Stop doing fixed releases altogether.

Once we adopt the rest of your proposal, what would be the added cost of
actually still doing "releases", that could serve as reference points in
time and install media ?

With a well-oiled release process, the cost is not high. And keeping
that logical name to describe a point in time has benefits: reference
install media, time-based cycle to focus development community, media
attention, LTS mode starting point, easy way to describe a set of APIs
and everything else you have in [B] above.

If you think of a "release" not in term of upgrade and maintenance but
in terms of a development milestone and a breathing rhythm, I think the
benefits outweigh the costs. And it's certainly compatible with the rest
of your proposal.

-- 
Thierry Carrez (ttx)
OpenStack