<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/4.6.0"> </HEAD> <BODY> On Fri, 2013-03-01 at 12:10 +0100, Loïc Minier wrote: <BLOCKQUOTE TYPE=CITE> <PRE> On Fri, Mar 01, 2013, Martin Pitt wrote: > I don't think that's feasible with a RR model. We don't even control > most of the APIs that are in Ubuntu even. > > As Matthew Paul Thomas and others pointed out, we primarily want to > recommend the LTS releases on the download page and for most users, so > that's certainly what ISVs should target, too? I don't think we can make any commitment against all of Ubuntu or all of main, but we could pick a subset by product and commit to some level of API and ABI support for this subset. e.g. this blessed set of core libraries would be guaranteed to be included in the next LTS, this blessed set of Unity APis would be available in the Touch and Desktop releases, this blessed set of KDE APIs would be available in the next release etc. </PRE> </BLOCKQUOTE> I think what we can do though is freeze the interfaces early before an LTS so that App developers have an opportunity to target them BEFORE the LTS comes out. We want the release day of the LTS to be as big a day for them as it is for us. I think that another thing that we can do is commit to having the API/ABI's from the previous LTS available in the development release. They might not be the default targeted ones, or come by default, but that way if someone who was using Ubuntu RR wanted to install a game that was targeted at the last LTS it is likely to work. I see this as roughly akin to multiarch, but slightly more fun. Ted </BODY> </HTML>