The following scenario is not elaborated in the documentation and actually was discussed in another thread. I just wanna double-check how does store behave in such a case today.
E.g
I requested 17.06 track for docker-snap, and that track holds docker 17.06.0 Quarterly release and subsequent bug fixing versions(17.06.1, 17.06.2…etc).
3 months later, when 17.09 quarterly release is out, another requested track 17.09 is opened up for docker-snap and we use it for 17.09 snap package publishing.
Then how can end-users upgrade docker snap to 17.09 if 17.06 is installed previously?
What’s the store’s behavior if we explicitly close 17.06 track by running ‘snapcraft close 17.06’? Do people stay at 17.06 track forever or store internally fallback to next track here? If it’s the former case, does that mean people have to upgrade to latest track(17.09) manually?
Thanks
Hi Gary,
These details seem covered in the text above. I’ll explain again below, but please let me know what wasn’t clear.
If they are on the latest track, they don’t have to do anything. If the installed the 17.06 track, they need to get out of it.
At this point there’s no provision for closing tracks, as that would be extremely aggressive and break down anyone that relied on the promise of installing a snap from a given series of versions, which is the whole point of having tracks in the first place. We’re planning to allow hiding of tracks, though.
Nothing magic happens. The reason tracks exist at all is to allow people to pick a series of versions and stay with it. We can’t offer that as a feature and then magically shift which series is being used.
Thanks for the detailed explanation.
Considering the store’s behavior and the situation we’re currently in, I’d explain it in full detail at this point to stakeholder and avoid subtle problems with decision making.
