Handling versioning of platform snaps

[Mark Shuttleworth]

Hi Tim

Welcome aboard, and thank you, this is exactly the type of question we
want to be solving together on this list.

The simplest approach would be to insert a major version/ABI indcation
in the platform snap name. Something like lirios3 and lirios4 would be a
very explicit way to provided different versions of your libraries. It
would have the major benefit that both platform snaps could be installed
at the same time, too, enabling a more natural app transition (each app
can choose when to hop from 3 to 4) rather than a big-bang flag day for
each device. The downside would be the incremental size of having both
installed at once during that transition, but we continually see that
'time is more precious than disk space' so giving users a low-friction
way to 'just work' is more useful than saving 0.2 GB of their 1 TB disk.

It might be worth looking into the linking of apps to particular tracks,
but this raises a lot of tricky questions that I suspect would be a
swamp with more problems than solutions.

Does that sound like a reasonable starting point?

Mark

On 06/03/17 10:01, Tim Süberkrüb wrote:
> Hey everyone,
>
> as a member of the Liri OS project <http://github.com/lirios/> I'm
> working with our team towards providing our applications as snap
> packages. All our apps depend Qt and our custom UI framework (Fluid).
> Because of that we considered creating a platform snap similar to the
> ubuntu-app-platform
> <https://insights.ubuntu.com/2016/12/08/using-the-ubuntu-app-platform-content-interface-in-app-snaps/>
> as a good way to bundle our dependencies and minimize disk space
> usage. To archive this we're using the content interface (see
> snapcraft.yaml
> <https://github.com/lirios/platform-snap/blob/develop/snap/snapcraft.yaml>).
>
>
> However, while evaluating this option, we considered the following: It
> is inevitable that we will at some point have to break compatibility
> of the libraries present in our platform snap. Because of different
> release schedules it is unlikely though that we would update all apps
> at the same which would result in breaking them as soon as the user
> downloads an incompatible update of the platform snap.
>
> As discussed on rocket chat
> <https://rocket.ubuntu.com/channel/snapcraft>, we are looking for ways
> to solve this problem. Our initial assumption was that the content
> interface would allow having separate versions of the platform snap
> installed as long as one installed app requires it. But this appears
> to be not possible by design.
>
> However, it seems possible that tracks and channels
> <https://snapcraft.io/docs/reference/channels> could provide a
> solution to this problem. This would allow us to use a separate track
> for incompatible platform snap versions if there is a way to specify
> for the individual app snaps which track they expect for the content
> interface (like it is possible to set the "default-provider"). Is
> there such an option? If not, would this be a possible addition to
> snap in order to allow use cases like this? Or is there a better way
> to solve the detailed issue?
>
> Thanks in advance for your help!
>
> All the best,
>
> Tim
>