Follow Up from "Let's Discuss Interim Releases"

[Thierry Carrez]

Robert Collins wrote:
> On 11 March 2013 23:12, Thierry Carrez <ttx at ubuntu.com> wrote:
>> Robert Collins wrote:
> 
>>> 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.
> 
> I don't agree here. There is [E] an install media in the 'what is a
> release', but 'has unchanging install media' is not an important thing
> in any user story I have seen so far. Dailies *from the released
> archive* are fine *today*, if we chose to publish them. AFAICT there
> are no use cases or user expectations to fail that are tied to how
> often install media are updated vs the already covered aspects.

I'm not saying you can't use dailies to care for "getting an install
media". You were listing what, technically, a release means today. I'm
just saying that as of today, "releases" also mean a reference install
media.

>> 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 ?
> 
> It is just a combination of options - feature flag values, so you
> could name each LTS combination 'precise' etc.
> 
> Or you could take a less orchestrated approach and just allow saying
> 'give me the default behaviour new installs had on <date>'. Then
> deprecation of support for a given thing is directly tied into that,
> and the UI can show people who are lagging warnings without needing to
> translate codenames.

I'm not sure I understand how this "configuration" would work,
especially with security updates. I'm probably missing something, so
let's have an example. Let's say I install "Ubuntu" on January 1st, 2014
and set it to "LTS mode". I get Gnucash 2.5. Alice does the same on
February 1st, 2014 and grabs Gnucash 2.6. Bob does the same on March
1st, 2014, gets Gnucash 3.0, which introduces a very large behavior
change. In May, a vulnerability is discovered that affects all versions
up to 3.0.1. The security team has to backport the fix to 2.{5,6} and
3.0 because all those LTS users expectation is that they will get "keep
me secure with my behavior unchanged" mode ?

Or are you saying that Gnucash 3.0, like all other packages in the
archive, should have a config option that says compatibility=2.x that
would preserve any past behavior, letting the security team happily only
patch Gnucash 3.0 ?

>> 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.
> 
> I don't understand what you mean by 'point in time' here. Could you
> expand on that?

I mean keeping the association between a name and a period in time.
"Raring is the development cycle that started in November 2013 and ends
in April 2014".

Then you can anchor a number of things to that artificial "rhythm" you
created: sets of API versions for your API deprecation policy, reference
install media if you still want them, common community development
cycle, etc.

My point is that there is value in having a cadence, and the cost of
special-casing a few dates is not that high to pay.

-- 
Thierry Carrez (ttx)
Ubuntu core developer