System framework for apps

Registered by Pat McGowan on 2013-11-12

We define a system framework for apps to specify for compatibility. The planned changes for 14.04 need to be defined.

Blueprint information

Status:
Not started
Approver:
Pat McGowan
Priority:
Essential
Drafter:
Sergio Schvezov
Direction:
Needs approval
Assignee:
None
Definition:
Drafting
Series goal:
Accepted for trusty
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

Review the 13.10 definition
Define the set of changes planned for 14.04
- Qt 5.2
- Cordova 3.0
- UI toolkit update
- other major system level components
Should autopilot be considered part of the framework?
Can we validate the API set used by apps?
Should version naming coincide with the ubuntu releases?
Does the sdk-libs seed need updating to include additional packages?
Should sdk-libs explicitly include the entire set of packages representing the supported API set, and not rely on implicit support due to dependencies?
Are there other versioned formats that are relevant, like desktop files, manifests?

The main definition is provided in the sdk-libs metapackages in the
https://launchpad.net/ubuntu/+source/ubuntu-touch-meta project

[sergiusens]: I would also like to see something like this: For each Android release, there are XML files describing the signatures of all public APIs contained in the release. The CTS contains a utility to check those API signatures against the APIs available on the device. The results from signature checking are recorded in the test result XML file.

[jdstrand] note that changes to APIs require apparmor policy changes. apparmor policy is versioned by vendor (ie, 13.10 has ubuntu policy 1.0). When we change framework definitions, we will almost certainly need to rev the ubuntu apparmor policy. 14.04 will have ubuntu policy 1.1.

Click frameworks allow expressing platform dependencies, we probably want one for 14.04, but we also need to think about higher level problems

What do we tell app developers to build against?
What do we build our own Click packages against? At the moment Clicks are built against saucy
How do we support building against SDK versions? build a saucy chroot to build them
How do we support running apps against older/newer releases?
What is our promise of ABI stability? API stability?
How do we publish the list of APIs and ABIs supported (aka. part of the Ubuntu SDK)?
Who is going to write/integrate/deploy tools to automatically flag ABI and API changes?

We could either include compatibility sources in the archive (e.g. introduce a qt5.0 source) or we could include a runtime chroot
The former approach would require ABI checkers, for all our supported runtimes
Generating a chroot seems very heavy in terms of disk usage, might have to support 3-4 releases in parallel, of some hundreds of MB each

We dont need to support 14.04 up to LTS lifetime
Ideally we would like to promise ABI and API stability for ever. However this has a cost. An upper bound might be the supported timeline of the Ubuntu releases. But it could be a lot less than that.

Should split in multiple frameworks (e.g. QML, C/Qt, HTML5/Cordova)

Would want some metrics to tell how stable frameworks are

How do autocomplete the right QML API from the SDK?
- we could use the SDK chroot to autocomplete; this kind of goes against running things on your system though
- or ideally we can apply the same approach as on the phone to support old releases on Ubuntu desktops (and install supported frameworks on the desktop)

Should explore possibility of:
- keeping libs backwards-compatible
- shipping chroots of removed/old/incompatible libraries of older frameworks
- use these in devices and on developer systems

How long do we support frameworks? Needs discussion, but could be based on number of packages using this or that framework
But eventually frameworks will not be updated anymore

There are different timeframes for:
1. how long can one target a framework from the SDK
2. how long will OEM/carriers/ODM allow OS updates -- some devices might be stuck in the past
3. how long does a framework get updated (security fixes and such)
4. how long do we allow running apps against old frameworks in the most recent OS

Do we want a feature to allow targeting newer frameworks than the one you declare as the minimal framework
- probably don't need to worry about this now
- could also allow having multiple versions of the same app in the store targeting different frameworks

(?)

Work Items

Work items for ubuntu-13.12:
[pat-mcgowan] schedule followup: INPROGRESS
[pat-mcgowan] review other frameworks for their support policies: DONE
[abreu-alexandre] Define webapps framework: TODO
[abreu-alexandre] Define HTML5/Cordova framework: TODO

Work items for ubuntu-14.01:
[sergiusens] Define officially supported C/C++ libs (Qt, platform-api....): TODO
[sergiusens] Write C/C++ ABI checker for platform-api and C/C++ libs to make sure they dontchange ABI/API: TODO
[bzoltan] Write ABI/API checker for QML components to make sure they dont change ABI/API: TODO
[xnox] Update list of frameworks, e.g. one for QML, one for C/C++ libs, one for HTML5/Cordova, one for webapps - [xnox] no package set changes needed, any package seeded into sdk-libs can start providing "click framework file" if so is desired: DONE
Plan to write tools to check that a package is using official libraries/modules: TODO
[lool] Discuss how to support multiple frameworks on devices and developer systems: TODO
[lool] Discuss how long we support frameworks if not forever; could be dicated by number of apps using a framework: TODO

Dependency tree

* Blueprints in grey have been implemented.