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