Avoiding fragmentation with a rolling release

Matthew Paul Thomas mpt at canonical.com
Sun Mar 3 21:44:42 UTC 2013


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

Colin Watson wrote on 03/03/13 18:28:
> 
> On Sun, Mar 03, 2013 at 10:48:21AM -0500, Michael Hall wrote:
>> 
>> 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.
> 
> Let's be clear about our thinking on this or we won't get anywhere.
> The problem is not libraries being upgraded to a new major version.
> The problem is the older version no longer being provided.
> 
> ...

This is getting a bit far from my area of expertise, but as I
understand it, only one of the three examples I cited originally could
have been solved by providing two library versions alongside each other.

Here are the references:

Matthew Paul Thomas wrote on 28/02/13 20:14:
> ...
> 
> During the Ubuntu 12.10 development cycle, the messaging menu API 
> changed for architectural reasons. Every application using it 
> broke, but that wasn't so bad -- because end users weren't using 
> it, OS developers expect things to break, and most of those 
> applications were fixed before the 12.10 release.

"FFE: libmessaging-menu transitions for quantal"
<http://launchpad.net/bugs/1040259>

An example of a third-party app failing to cope: "Needs updating on
Ubuntu 12.10 : change in libmessaging-menu api"
<http://trac-plugins.gajim.org/ticket/14>

> But if that change had happened during a rolling release used by 
> end users, either end users would have experienced the breakage,
> or we would have had to pay the cost of reimplementing the old API 
> alongside the new one. That would be a cost our competitors do not 
> pay -- or pay only because they benefit from vastly more and older 
> third-party applications than we do.
> 
> That is not an isolated case. There have been similar API changes 
> for application indicator menus,

This one was, and is, addressed by shipping multiple libraries.
<http://packages.ubuntu.com/search?keywords=libappindicator1>
<http://packages.ubuntu.com/search?keywords=libappindicator3>

(Though I'm told that if you're new to Ubuntu development and you "from
gi.repository import AppIndicator", you get the wrong one. Yay.)

> for Unity lenses and scopes,

January 2012: "Now, as some have picked up, the Unity Lenses API has
changed slightly in Unity-5.0 (the version that'll be in Ubuntu
12.04). First of all; sorry!" <http://www.grillbar.org/wordpress/?p=585>

> and probably for subsystems I've never even heard of. With an 
> end-user rolling release, if you installed OS updates overnight,
> an application you had paid money for could stop working while you 
> slept.
> 
> ...

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

iEYEARECAAYFAlEzxEoACgkQ6PUxNfU6ecosKwCeK705CUB9dy3MAU39EW+AaNT3
OpYAnRqmEVoXDwcPRKYvzANDRTKfcyno
=r6LZ
-----END PGP SIGNATURE-----



More information about the ubuntu-devel mailing list