Snaps targeting Ubuntu releases

Martin Albisetti martin.albisetti at
Mon Mar 30 16:43:43 UTC 2015

Hi all,

We would like to move away from depending on base framework in Snappy,
and instead target the release version and (optionally) any number of
frameworks that extend the system's functionality.
In order to do that, snap packages need to be able to target releases.

Here's my strawman proposal.

tl;dr: The release version(s) targeted will be specified in the store
on upload per each version, allowing the same untouched binary to
target future versions without having to re-upload.

Now, for a less short version.
A key driver for thinking about how to implement this is how to avoid
having zero (or close to zero) apps on the day of a new release.
Remember, in this new and exciting world we don't get to re-build apps
as we don't have the source for them, we didn't compile them
originally and we don't control what or when it gets uploaded. Apps
are also disconnected from release dates, they have their own
ecosystems, caretakers and release cadences. Releases go out, and
while we will guarantee a stable and secure base system, apps will
continue to evolve throughout the release's lifespan at the pace each
upstream developer wants to push.
As for how to implement it, If the release version (15.04. rolling,
16.04-alpha1, etc) is specified in the manifest for an app (like in
debian packages), targeting new versions means the developer has to
re-package the app each time. If we go fast enough, we will drop a lot
of apps on the way there as developers stop wanting to re-package apps
that often. Or the opposite might happen as well, you make an app for
15.04 which works fine in 16.04, but can't really remember how to
re-package it 2 years later so just ignore it and it's unavailable in
But we still want it to be an explicit decision to target a release,
although that could be ours as the ecosystem curators (we validated
that an app works in a newer version)  or the upstream developer did,
targeting new versions for packages that don't need to be re-compiled
should be as easy as possible.
In a Snappy world, it will be a lot more likely an continues to work
across releases since the core is very small and packages wlll bring
with them the vast majority of dependencies, statically linked.

My proposal then, is to simple add a list of releases with checkboxes
on upload, where we will pre-fill it for you in subsequent version
uploads for convenience, but tell the store what release(s) you
support separate from the actual binary you are providing.
We could optionally support specifying that information in the
manifest itself, for fully automated uploads, where it's only a
"suggested" piece of information for the store that is completely
ignored client side. If we find an elegant way to specify that so
people aren't confused upon inspecting an app that says "15.04" in the
manifest file but is successfully installed in 16.04, it would be
convenient to do so (essentially, a piece of metadata only relevant to
the store, not the device its installed on later).

This also makes rolling roll smoother.

Overall, the implementation feels straightforward and clean:
- The client just tells the store what release it's on, the store
pre-filters results that will work for it
- The client installs whatever the store gave it
- The store just adds one more piece of information requested on
upload to the developer
- Come release time, we can run installability reports against the
most popular apps in the store and on success either suggest
developers tick the box to target the new release, or we can do it for
them for convenience
- Frameworks are now an optional field for snap packages


More information about the snappy-devel mailing list