Handling versioning of platform snaps

[Tim Süberkrüb]

Hey Sergio and Mark,

thanks very much for your help.

After discussing different possible solutions in the team and the 
conversation on rocket chat I think that this is probably the best 
solution currently possible. We also considered other ways like placing 
different library versions in the platform snap but that would be in the 
end much more hassle and much more hacky than separating them.

Nevertheless, I still think there could be a better and more convenient 
solution for this use case though - at least in theory. Sergio explained 
to me that it is not possible to have different versions of the same 
snap active, which is - I assume - the main reason why it's impossible 
to use different versions of the same runtime/platform snap, while 
Flatpak offers this functionality.

I'm not familiar with the technical details of snap. There might be 
technical or other reasons why this is not something snap should offer. 
But if it is possible, I think it would be very reasonable to allow 
snaps to specify a specific version for a content interface plus being 
able to have separate versions of the same snap installed as long as 
another app depends on it.

This would - if implemented flexible enough - not only benefit our 
specific use case but anyone who would like to control versioning of 
snaps connecting with the content interface (e.g. a snap that supports 
specific plugin versions of some sort of extension).

Again, this is just a suggestion, that I as a user without much 
knowledge about the internals find reasonable. This might not fit in the 
concept of snaps for a good reason.

Thanks for bearing with me!

 > [...] garbage collect all the liriosX-1 snaps that are not connected 
to anything (or whatever number makes sense with rollbacks and current 
garbage collection rules

I think that would be good to have!

Have a nice day,

Tim

On 07.03.2017 14:55, Sergio Schvezov wrote:
> On Tue, 7 Mar 2017 05:06:46 -0800, Mark Shuttleworth wrote:
>> 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?
> This is what I suggested during the rocket chat conversations and I agree it is the best way to move forward. What is interesting here is (once there is support to bring in default slot implemetations for an interface), to garbage collect all the liriosX-1 snaps that are not connected to anything (or whatever number makes sense with rollbacks and current garbage collection rules).
>