The more I think about this, the more I think this should be pushed to the application developers.
SNAP already supports tracks. I couldn’t find if there’s a limit on the number of tracks, but assuming there isn’t, it should be up to the application developer to set tracks for versions.
So in the case of the OP, he can build out tracks for every version of his networking applications
1.1, 1.2, 1.3…
He could then tell his customer to choose a particular version to ‘stick to’. It would then be up to him to ‘not’ update his tracks so then nothing would auto update.
In the event of a security emergency, the OP still has the ability to ‘push an update’. Let’s say he’s at version 5.0, but there is a critical flaw in 1.1. The OP can then put in a fix for those branches and force an update. Which I think is the idea.
I think this kind of guidance would work well and offloads all this auto-update discussion to the applications themselves. If you don’t want auto-updating, bother the application developers to have a lot of tracks 1.1.1, 1.1.2… blah blah
For anyone who still doesn’t want apps to update, SNAP can push their store proxy as the way to stop that or fudging with networking.
A good write up for app developers and a page to point to would resolve offload all this from SNAP.
Don’t get me wrong, I still think you should be able to stop updates on a per app basis via an easy configuration or something, but if that’s really not in the cards, then I think the above makes sense.