@lexa Thanks for starting the conversation and for sharing your views.
I’d also welcome Marius’ thoughts on shifting from naming versions using only the major version to using the full semantic name. I believe Neutron does this (example) and thus uses governance for all upgrades, but it also introduces the risk of human error in failing to keep the release and upgrade name in sync (example from Neutron).
This shouldn’t be a problem. We used only the major version until now just because we didn’t need to use the minor. We never had a software upgrade proposal to bump minor versions of Gaia.
Imo, the biggest risk in using governance for emergency upgrades is when we are fixing a major security vulnerability.
In my view, emergency upgrades for both major and critical security vulnerabilities should not go through governance at all. Even sharing publicly that there is a critical vulnerability on the Hub would help attackers to exploit it.
would it be possible to put an upgrade on chain and point it at a repo where the fix will be published 24h in advance of upgrade height, the way we currently do for coordinated emergency upgrades? Like we set up the upgrade proposal to happen but don’t actually reveal the binary until we know the proposal is going to pass and it’s safe to reveal the fix.
I think this should be possible as the binaries are just provided in the info field of a software upgrade proposal. We actually had scenarios where we asked the validators to use another binary than the one in the proposal (e.g., the v15 upgrade).