But there's more.


Goto ---> Oliver comment #26
=============================

> (along with the fact that you can always roll back to any former snap or snapd version and due to the fully transactional nature of snaps this needs to be fully backwards compatible as zyga mentioned above)

Yes agreed. It would seem that is a heavy consideration because this is an LTS Release now.

[expanding on this concern]

I would suggest that this, as a break change (fixing the epoch and preventing version rollback) in LTS... it should be done during a period when no other features or bugfixes are being released for snapd. That will significantly reduce the risk of any other bugs sneaking in there, on UNCONNECTED features. Which might otherwise require the user to roll back. For unconnected reasons. Then the risk is minimized as much as is feasible.

> ...so please be patient ;)

Yes. But after 2 years of open bug, can we get a more updated timeframe on that?
For example: is 4 years a realistic expectation? Given other broader milestones?

(... that would mean by the next 20.04 lts release)

This fix is aligned with the epoch feature milestone in snapd.
But are there any other pressing large milestone requirements?
Because I cannot seem to find them.

So what is stopping to get the rest worked out, and lined up in the meantime?
To make sure that it's ready beforehand.

Either the belief is that all this other associated work is far too complicated.
And demands a big block of time dedicated to it. (which is pointless without epochs)

Or the belief is that this work is actually far too simple, compared to snapd epochs, which is still very far away.

Therefore it would not matter to do nothing here. And be best / more tidy to just dedicate all the time to epochs first instead, and get that fully out of the way. Since that is critical for this one. Then come back to this afterward. (if we needs only spend a tiny little time on this bug, it wouldn't make any difference).


> plus other things (eg, do we allow both directories?

Nope. Absolutely not. Because there is only 1 environment variable (SNAP_USER_DATA=)

> If we allow both, what does that mean for the home interface? Do we allow compatibility symlinks?

You probably do not need to worry about that ^^. If you did 'no' for the previous question.
And if you do not permit duplicate real folders (of the same thing...)

> Do we do a data migration?

If you want to move ~/snap to a hidden folder, then create a symlink in its place.
That is probably fine by most people. And it solves the previous question.

> Do we do data migration upon revert of the core snap?

I am guessing that this question was already answered previously above ^^, but i'm not sure.
Maybe its about something else instead IDK.

> What happens to applications if the only core snap is reverted, if only the app snap is reverted, if both are reverted?

I am guessing that this does not happen very often, typically never.
Unless there is a pressing technical reason which forces the user to revert a snap.
Therefore I believe that this is unlikely to matter much.

At best, if the app cannot find it's user data anymore, and writes to the wrong folder by mistake? 
Then that is not such a terrible breakage. Unlike other possible kinds of failures and breakages.

If user's existing data is not lost (it should not be)...
That is mostly a guess. But i think an appropriate one, given the situation the snap would find itself in.

It sounds like it could be rectified pretty easily with some manual intervention.
But since it's an unlikely scenario, that would seem like an appropriate solve.

> How do we handle snaps that hard-code ~/snap/... instead of using $SNAP_USER_DATA and $SNAP_USER_COMMON

Given a lack of information, I am assuming that these snaps are written badly
And therefore do not conform correctly to the snap packaging standards.

Which sounds (to me) like a different, but related issue, to be tackled elsewhere.
I did give some extra thought to that. Just not sure if it matters for this one though.