Handling versioning of platform snaps

[Tim Süberkrüb]

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