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 mhall...@ubuntu.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel