Blueprint changed by Matthew Paul Thomas: Whiteboard changed: * Create a public Launchpad team (say, ~ubuntu-appdev) that isn't moderated and anyone can join * Create a PPA associated with said team (say, ubuntu-appdev/developer-channel) that would be used as the rolling-release LTS-to-LTS channel * Fork LTS candidate apps off of that channel into another PPA associated with that team (say, ubuntu-appdev/lts-beta) and fix the bugs in them at least 9-12 months ahead of release to make the LTS releases more polished and stable. * When the LTS packages are ready to submit as new LTS releases, fork them off into yet another PPA (say, ubuntu-appdev/lts-stable) and they'll update on all LTS systems automatically + + The premise of this blueprint is incorrect. The approval process for USC + is not at all "because of Ubuntu's strict fixed release cycle". Quite + the opposite: it is a huge amount of work to test and reissue ISV apps + for new releases, and a rolling release would make this completely + impractical. In the worst case, an ABI change could make an application + you had paid for suddenly unusable. Now, a fixed six-monthly release is + harmful for many reasons, so I'm all in favor of switching to LTSes only + plus a *developer-only* rolling release. The biggest risk of this plan + is that a large proportion of Ubuntu users would be tempted to run the + rolling release instead of the LTS, decimating the addressable market + for ISV software. —mpt
-- Future releases: Proposal for implementation of separate LTS-to-LTS rolling release channel https://blueprints.launchpad.net/ubuntu/+spec/desktop-x-rolling-release-nonlts-proposal -- Mailing list: https://launchpad.net/~unity-design Post to : unity-design@lists.launchpad.net Unsubscribe : https://launchpad.net/~unity-design More help : https://help.launchpad.net/ListHelp
