Hi, we’d like to request a core16 track for Multipass.
We’re moving to base: core18, but in certain cases manual intervention is required (see related discussion here) before the user can do the move.
For that we wanted to maintain a core16 track to which the user could temporarily refresh, resolve the problem and go back to the new version. We’d close the track after a transition period.
As you mentioned on the related discussion, epochs might be a good fit, since preventing updates to newer snaps without going through a “transition” snap that can handle both user data formats/cases is precisely what epochs were designed for. I know @chipaca was working on epochs support on snapd, if he says it’s ready maybe it would fit your use case better.
In any case, +1 from me, keeping the old release on a compatibility track fits the tracks use case reasonably well and if you decide to use epochs instead, we can always not create the track requested here
The standard practice would be tell users that, if they want to stay on the old snap, they should explicitly switch to track core16, so they can then migrate at a convenient time for them.
There’s a 7-day waiting period to gather more votes (we need at least two positive votes from reviewers/architects); once the time has elapsed, I’ll check and act as per the state of voting at that time.