Avoiding fragmentation with a rolling release

[Matthew Paul Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Hall wrote on 03/03/13 15:48:
> ...
> 
> Does Zynga have to provide a different version of their games for 
> each different version of Android they support, or does Android 
> give them backwards-compatibility so that they can target 2.2 but 
> still run on 4.2?  I'm not an android developer, but I would
> assume it's the latter.  We could only do the same if we could
> ensure that the APIs available in an LTS would continue to be
> available in the following rolling release (at least up until the
> next LTS).

Right. And we couldn't practically do that, for the reasons I gave.
Google controls all of Android's APIs, in a way that nobody does for
Ubuntu. They have engineering resources to maintain backward
compatibility, in a way that nobody does for Ubuntu. And they have
writers to document all those API versions, in a way that we don't
manage for Ubuntu (though you do great work for a small subset).

What we might be able to do, though, is to freeze APIs sometime before
release. That would be more tractable than documenting -- or even
knowing about! -- changes to individual APIs.

In other words, along with UI Freeze, Kernel Freeze, and so on, we
could have an API Freeze. This might be three months, or six months,
or nine months before the release.

> ...
> 
>> So to provide a stable target for ISVs, it is vital that end 
>> users stick to the LTS.
> 
> Again I agree, but I don't think this was the original intention of
> moving to a rolling release.

Rick wrote, "I would expect the stock download page to *only* point to
the last LTS". We would need to make sure that other Web sites, the
app submission process, and so on align with this.

> Would this transition be considered successful if 90% of our 
> current 6-month release users switched to LTS rather than rolling?

Of PCs running Ubuntu 12.04 or later, currently 0.5 percent of them
are running the development version.

If the rolling release goes ahead and we end up with more than 5
percent using the development version, I think we'll have messed up. A
large chunk of Ubuntu's user base would no longer be using a
*platform*, in the sense of something upon which third-party software
and services can practically be provided.

> Because we still haven't solved the problem of getting newer apps 
> into older releases in an efficient manner.

True, but that doesn't mean it's solved -- or even solvable -- for the
development release! (All love and respect to Debian and the MOTUs,
but joining either of them isn't even meant to be "an efficient manner".)

Having LTSes as the only target releases wouldn't fix that problem.
But it would help, in two ways.

First, there would be many fewer versions to target. In the absence of
better evidence, let's say that "being issued with updates" is a
decent proxy for "in active use". (Because if they aren't, why
bother?) With the current model, three years from today, *five*
versions would be being provided with updates: 12.04 LTS (until April
2016), 14.04 LTS (until April 2018), 14.10 (until April 2016), 15.04
(until October 2016), and 15.10 (until April 2017). With the
LTS+rolling model, only *two* versions would: 12.04 and 14. Much better.

(That in itself is a strong reason to switch to this new model. Does
any Ubuntu developer think it would be a good idea to be issuing
updates for five OS versions at once? Even Microsoft doesn't try to do
that.)

And second, in some of the time saved by releasing less often, ;-)
Ubuntu developers could work on other parts of the problem. Making
packaging easier. Documenting the APIs they produce. Maintaining
compatibility for their own APIs for longer. And improving the upgrade
process, so that people upgrade to the next stable release faster and
more often, further reducing fragmentation.
<https://wiki.ubuntu.com/ReleaseUpgrades>

- -- 
mpt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEzxHUACgkQ6PUxNfU6ecrCmQCfZnWKKd+OQvO624CpBCpkodXd
s9oAoMjbENWhcrzg+6WGADKTdqRmPpdK
=iKh3
-----END PGP SIGNATURE-----