That’s pretty much what im arguing for:
-
there are non protocol breaking changes, those are boring. Just do the update, no one else cares.
-
for protocol breaking changes, you would install that update causing your node to signal support for it, but without actually enabling the protocol change. Those changes need to be enabled for the whole network at once:
- The moment an incompatible new global state is part of the networks data, no old node is supported anymore (old nodes are unable to read the newer messages anyway). (that’s the “Basically the later upgrade removes those old nodes from compatibility list.” part)
- including a feature in one version (“interim”) and then enabling it on the next release (“enabled”) wouldn’t work. That’s because the “enabled” version wouldn’t be installed all at once. Causing the network to be running a weird mix of “old” + “interim” + “enabled” nodes. And there’s no way for the “interim” nodes to know how many supporting (“interim” + “enabled”) nodes there are, so how do they know when to enable the change? When they see a message with the new version? But then a malicious actor could craft such a message and force all supporting nodes to enable the change prematurely, without having a majority of supporting nodes, they all get dropped off the network by "old"s.
So my issues with your approach are:
- you need a non-gamable trigger for the update, that is guaranteed to be triggered after a majority of nodes signal support for that update.
- with no consensus, no one knows how many operators are in favor of the update