The missing revisions were an unintended consequence of preparation for an upcoming retention policy change.
With more and more snaps providing daily edge builds, it’s neither practical nor useful for the Snap Store to keep them forever – nextcloud alone has many terabytes of them, and they’re practically never accessed on subsequent days. So we’re working on preliminary policy changes to expire old daily builds (e.g. only ever in edge and superseded more than six months ago), and nextcloud was a test case for the new rules, but a few stable revisions ended up erroneously unavailable too. We’ve made them all visible again.
Ah ha, yes that makes sense. Edge builds are rarely useful once they’re no longer the latest in a channel (rarely == never for me). I do find myself fetching old stable revisions though from time to time, even if they’re not the latest in the channel. I know you said you’re only looking to do this for revs released to edge, I just wanted to throw that out there as you potentially consider expanding.
Thanks for the information on your usage. The proposed criteria (only ever in edge, and not the current revision in the last six months) recover >85% of the space consumed by daily-heavy snaps like nextcloud, so they’re what we’re testing for now.
I don’t see an immediate need to prune old stable revisions, but that set obviously also does grow without bound over time, albeit much more slowly, so we’ll probably need to eventually bring in a policy there too.
Agreed. Generally my use-case is someone who didn’t auto-update for ages for whatever reason and then ran into an issue updating to the latest that I want to try and duplicate. I have only deep-dived years back into stable revisions once, and it was to release some of them into new tracks so I could have a better history. If we ignore that outlier, I think for my use-case if you bump the timespan out a year or two for stable revisions that will work just fine. Heck even if you started at 5 years you’d have a bound.
Thanks for the feedback @kyrofa. We are working on formalizing a policy and will add that to public documentation when ready. We will definitely start out pretty conservatively and would love to hear from others if there are any concerns with the initial “only ever edge, 6mo+ back” approach. We can post separately with an appropriate title when we get closer to finalizing the policy and implementing a larger/regular pruning.