Avoiding fragmentation with a rolling release

[Ted Gould]

On Fri, 2013-03-01 at 12:10 +0100, Loïc Minier wrote:

> 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.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20130301/7026df91/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20130301/7026df91/attachment-0001.pgp>