unity-design team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

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