-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Hall wrote on 03/03/13 15:48: > ... > > Does Zynga have to provide a different version of their games for > each different version of Android they support, or does Android > give them backwards-compatibility so that they can target 2.2 but > still run on 4.2? I'm not an android developer, but I would > assume it's the latter. We could only do the same if we could > ensure that the APIs available in an LTS would continue to be > available in the following rolling release (at least up until the > next LTS).
Right. And we couldn't practically do that, for the reasons I gave. Google controls all of Android's APIs, in a way that nobody does for Ubuntu. They have engineering resources to maintain backward compatibility, in a way that nobody does for Ubuntu. And they have writers to document all those API versions, in a way that we don't manage for Ubuntu (though you do great work for a small subset). What we might be able to do, though, is to freeze APIs sometime before release. That would be more tractable than documenting -- or even knowing about! -- changes to individual APIs. In other words, along with UI Freeze, Kernel Freeze, and so on, we could have an API Freeze. This might be three months, or six months, or nine months before the release. > ... > >> So to provide a stable target for ISVs, it is vital that end >> users stick to the LTS. > > Again I agree, but I don't think this was the original intention of > moving to a rolling release. Rick wrote, "I would expect the stock download page to *only* point to the last LTS". We would need to make sure that other Web sites, the app submission process, and so on align with this. > Would this transition be considered successful if 90% of our > current 6-month release users switched to LTS rather than rolling? Of PCs running Ubuntu 12.04 or later, currently 0.5 percent of them are running the development version. If the rolling release goes ahead and we end up with more than 5 percent using the development version, I think we'll have messed up. A large chunk of Ubuntu's user base would no longer be using a *platform*, in the sense of something upon which third-party software and services can practically be provided. > Because we still haven't solved the problem of getting newer apps > into older releases in an efficient manner. True, but that doesn't mean it's solved -- or even solvable -- for the development release! (All love and respect to Debian and the MOTUs, but joining either of them isn't even meant to be "an efficient manner".) Having LTSes as the only target releases wouldn't fix that problem. But it would help, in two ways. First, there would be many fewer versions to target. In the absence of better evidence, let's say that "being issued with updates" is a decent proxy for "in active use". (Because if they aren't, why bother?) With the current model, three years from today, *five* versions would be being provided with updates: 12.04 LTS (until April 2016), 14.04 LTS (until April 2018), 14.10 (until April 2016), 15.04 (until October 2016), and 15.10 (until April 2017). With the LTS+rolling model, only *two* versions would: 12.04 and 14. Much better. (That in itself is a strong reason to switch to this new model. Does any Ubuntu developer think it would be a good idea to be issuing updates for five OS versions at once? Even Microsoft doesn't try to do that.) And second, in some of the time saved by releasing less often, ;-) Ubuntu developers could work on other parts of the problem. Making packaging easier. Documenting the APIs they produce. Maintaining compatibility for their own APIs for longer. And improving the upgrade process, so that people upgrade to the next stable release faster and more often, further reducing fragmentation. <https://wiki.ubuntu.com/ReleaseUpgrades> - -- mpt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEzxHUACgkQ6PUxNfU6ecrCmQCfZnWKKd+OQvO624CpBCpkodXd s9oAoMjbENWhcrzg+6WGADKTdqRmPpdK =iKh3 -----END PGP SIGNATURE----- -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
