Avoiding fragmentation with a rolling release

[Michael Hall]

On 03/03/2013 01:28 PM, Colin Watson wrote:
> 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.  For example, we
> have at least six versions of Berkeley DB in the archive, the oldest of
> which I added to Debian in 2002 in order that old versions of a certain
> proprietary web server would keep on working; there's been no reason to
> ever remove it since then, as it accounts for very little maintenance
> effort.  This is not rocket science; it just isn't worth doing unless
> there's a specific motivation.
> 
> In general, we clean up old versions of libraries after their SONAMEs
> change because it saves on scarce maintenance effort, package index
> download time, and things like that.  But that doesn't mean that we
> couldn't go to some special effort to keep older versions around in
> cases where we've made some promises about them.  If we actually had a
> documented list of cases where we cared about compatibility - or we
> could even generate this after the fact from app metadata - then we
> could ensure that all the relevant packages are still available in the
> next LTS, and document their obsolescence so that app developers know
> they need to move on.
> 
> This accounts for the vast majority of cases.  There's a smaller number
> of cases where semantics change incompatibly, and we'd need to pay
> attention to those on a case-by-case basis; but I think this is a much
> smaller and probably more tractable problem.
> 

>From an app developer's perspective, I would be happy with this
solution.  If it wouldn't add an unreasonable amount of added effort or
resources, then I think it is something we should do.  At the very lease
we need to cover those APIs that we consider part of the overall Ubuntu SDK.

--
Michael Hall
mhall119 at ubuntu.com