Avoiding fragmentation with a rolling release

[Michael Hall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/03/2013 09:18 AM, Matthew Paul Thomas wrote:
> Michael Hall wrote on 01/03/13 16:21:
> 
>> On 03/01/2013 12:34 AM, Martin Pitt wrote:
>>> 
>>> Michael Hall [2013-02-28 22:04 -0500]:
>> ...
>>> 
>>>> Personally I don't think "target only LTS releases" is going
>>>> to be acceptable to most ISVs, especially those writing
>>>> consumer "apps", where you can go from nobody to the most
>>>> downloaded and back to nobody in the span of 2 years (think
>>>> of the rapid rise and fall of games like Words with Friends,
>>>> or Draw Something).
>>> 
>>> How is that related to the platform they target? If anything,
>>> it seems to me that targetting LTS only is going to make
>>> things easier for this kind of "ephemeral app" use case, as it 
>>> significantly reduces the required maintenance and porting of 
>>> those?
> 
> Exactly. The minimum OS requirement for even the latest version of 
> Words With Friends is a two-year-old version of iOS (4.3), or a 
> *three*-year-old version of Android (2.1). And similar for Draw 
> Something (4.3 and 2.2).
> 
> One can only conclude that if Zynga ported their games to Ubuntu, 
> they'd be quite happy with 90%+ of users using a
> nearly-two-year-old version.
> 

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).

>> It depends on who is using the LTS and who is using the rolling 
>> release. If a significant number of our users are on the rolling
>>  release, or if an important demographic (say, technology
>> leaders, or people willing to pay for the latest and greatest)
>> are on the rolling release, then ISVs are going to want to target
>> that.
> 
>> ...
> 
> That is impractical for several reasons. Ubuntu developers don't 
> control most of Ubuntu's APIs. Even for those we do, maintaining
> (or, in some cases, reimplementing) old APIs alongside new ones
> would multiply Ubuntu developer effort. And as you know, we barely
> even have time to document the APIs in stable releases now, 
> <http://developer.ubuntu.com/?s=launcher+badge> 
> <http://developer.ubuntu.com/?s=spellchecking> 
> <http://developer.ubuntu.com/?s=animation> let alone being able to
> say "use this API if targeting the rolling release from October 4th
> to February 21st, and this other API for later dailies".

I agree, it was one thing when we would keep the same version of a
library for 6 months at a time, but with a rolling release you could
have one library or another being upgraded to a new major version
every week. So unless those upstreams committed to
backwards-compatibility, all of the work for providing that would fall
to us.

> 
> 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.  Would this transition be considered
successful if 90% of our current 6-month release users switched to LTS
rather than rolling?  Because we still haven't solved the problem of
getting newer apps into older releases in an efficient manner.

- --
Michael Hall
mhall119 at ubuntu.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRM3DFAAoJEInUYcGJgfVyQ+EP/2ukekaB6D6rBzD+gcBNPAC/
w9WBY8lIYEuF9Izf1m1KTrogNRsEyvsuLUgGaLGnPScj1OQxsCfaExKTwW9ux+aM
WvSh2/FZZmPo+G8eLim/JXca6rY3iGNV5NMJ1cvvbXZfJqMq6DuBSoZD9JNPlrFg
Gjz0xRAVLZuvFgo7idtyYMlua6+jYxnhyw84jYZ2d4btlxJEEA80BXYJjS1oBlDK
AAbVpSBFk8bvDaAOX9lEJ60VbE63Bf4pPasqzxCYA3ZwcNFfxf+kL+Rz5BWz5PAJ
RMBJE4XYikror92tKb/Yoy5dP7izCPRs//FvReamfZ+ItTudAqqaIQ9J5cl1PuiW
j29YdU5nwm/8RvcKasAVTLt4S92IN8bPB6EHqzkcEotePSqnqxIZRM+w7MGm7g1T
g40EUmLbMIjcAG9sFG7lUrGXU6VM/f9aLvY532TH/9wMzW3h4QEQwq1OpqokNiA/
CoxNARPTTM1jO08091siWdqP3D+NCqHNKc1mnG2S00f7MaYnd5SL8zNQ6r4PdwBw
ZbrJ0eMgSKqmqFzJ6HbeeHPCc5ompkqxMKbZtcABbsO4Uggj1wuqAd2kWHjgh61a
uMwS6/A7fh8of6SQDS5lvZv2bTtPfheq0hCZdcE4SkDcjvWTmLxliOjjeQrIrVeo
dkUbtvNBuz8AaGQGvf6n
=HW44
-----END PGP SIGNATURE-----