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 16.04. 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 -- Martin -- snappy-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel
