I am wondering if the versioning practices described here were devised in a wrong mindset. I would argue that protocols are made to be versioned differently compared to applications that use them, because the impact of a version switch in a protocol is not local to the application that made the switch, but affects all other participants on the bus. Therefore, to keep the bus maintainable, we must strive to make a major version update as rare as possible, making it a truly last resort option. Compared to the profound effect that a protocol version update has on the entire bus, the possibility of breaking a code compatibility on a particular single node seems like an insignificant nuisance for the developer.
The versioning approaches described above seem to be centered on the application, as if we were evaluating the bus in the scope of a local node. I would argue that this approach is unnecessarily low-level and offers a rather limited perspective, as it disregards the bigger picture of inter-node compatibility; rather, we should view the bus on the level of inter-node data streams, delegating the lower level issues, such as that of the code compatibility, to levels of abstraction that the specification does not concern itself with.
Even if we were to disregard the above, I would like to refute the specific arguments given above: “Automatic update to the newest version of a definition is nice” and “Not having code compatibility doesn’t give us much”. While nice, the code compatibility guarantee would also limit the scope of minor version changes to the point where it wouldn’t make much difference which particular minor version of a definition is used, since they all will be more or less functionally identical. The specific example where a new field is added in a code-compatible way does not seem to work well because in order to make use of the new field, one would have to alter the code, thus negating the advantages of keeping its compatibility.
I still don’t think that adding any additional constraints besides the already existing two (bit compatibility and semantic compatibility) would benefit the protocol.