This question occurred to me when looking at the recent problems with the snap-store snap. To keep things brief, this is a short summary of what happened:
- An update to the gnome-3-34-1804 platform snap revealed a problem in the snap-store snap: it included a copy of a library shadowing one from the platform snap, which was missing some symbols required by other libraries from the platform snap.
- An update to snap-store was rushed out that stopped bundling the problem library.
- Due to a change to the gnome-3-34 extension, there was a change in behaviour that prevented snap-store from detecting that it was connected to the Internet.
I will grant that we should have tested the update more before pushing it out to users. I also tend to think the extension change that triggered the second problem is beneficial on balance.
However, it points out that it can be difficult to push out a minimal change bug fix release of a snap that uses extensions. As extension updates are bundled with new Snapcraft version releases, you’d probably need to figure out which Snapcraft version your previous revision was built with and use that.
And because we distribute Snapcraft as a snap, it’s not obvious how you’d get hold of the old Snapcraft release in the first place. We’ve got a
4.x track for Snapcraft now, but this extension change happened between two 4.x releases. And even if the store let us download obsolete revisions of Snapcraft, we’d need some way to tell the Launchpad builders which revision to use.
I realise that something like this also has its downsides: many snaps have also benefited from automatically receiving improvements when built with new versions of Snapcraft, and that might stop happening if they need to opt in to using the fixes. Maybe optional pinning would be a reasonable middle ground?