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
> o
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 a
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 p
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. Somethi
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 dif
