Handling versioning of platform snaps

[Tim Süberkrüb]

Hey Mark,

thank you for explaining this, the reasons are clearer to me now.

 > In the case of libraries and frameworks, you don't have to worry about
 > persistent data that can or cannot be shared between the two versions.
 > You would need to know the two paths of the two versions *anyway* in
 > order to use them. THere is no semantic difference in your code between
 > /snap/foo-4.7 and snap/foo/4.7 so your own app code isn't going to be
 > more complex one way or the other.

You're right, that's a good point. The only difference is that it's slightly
harder to maintain because instead of maintaining different versions of 
one package
we need to maintain different versions of different packages. And for each
new version, a new name has to be registered which is probably going to 
be harder to automate.
Nevertheless, I agree, it is not such a big deal.
As for Liri, we're now discussing different options inside of our team.

I'm generally very happy with the developer experience of snapcraft and 
the user experience of snap and I'm really looking forward to see snaps 
running on Ubuntu phones & tablets.

Thanks again for taking your time to help us!

All the best,
Tim

On 08.03.2017 13:48, Mark Shuttleworth wrote:
> Snaps have a much stronger sense of identity. They *own* /snap/foo and
> that means you can build a much more predictable and reliable view of
> their behavior. Versioning is a key part of the snap story, it gives the
> user and the publiisher of the software a really *great* way to describe
> what they are releasing or what they are conuming on any particular
> device. The upstreams and the users that I have talked to generally say
> they *love* it.
>
> The fact that we know exactly where a snap is allows for rich interplay
> between snaps, like the way snaps can use the core snap, or other snaps
> through content interfaces.
>
> However, all of these things also required that we choose not to mount
> snaps in arbitrary locations. That ends up driving the requirement that
> you have administrative rights on a device if you want to change the set
> of installed snaps, and also that you can only have one active version
> at a time.
>
> In the case of libraries and frameworks, you don't have to worry about
> persistent data that can or cannot be shared between the two versions.
> You would need to know the two paths of the two versions *anyway* in
> order to use them. THere is no semantic difference in your code between
> /snap/foo-4.7 and snap/foo/4.7 so your own app code isn't going to be
> more complex one way or the other.
>
> Mark
>
> On 07/03/17 10:07, Tim Süberkrüb wrote:
>> 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).
>>>
>>
>
>