Knowing that changes can happen without it being expressed in the versioning system makes me a bit uneasy. I’ve accepted that whitespace/comment changes are allowed to happen if we have a tool verifying that it is in fact only comment/whitespace changes. But I honestly think it would be better to have a patch version that we bump even for these kinds of things. Introducing code compatibility for patch version would also make it a bit more useful and I, therefore, think this is the smart thing to do.
One of the most difficult things about programming is managing complexity, controlling (and being explicit about) mutability is an excellent tool for doing this as it becomes much easier to mentally reason about things if changes are obvious (expressed in some way).
I think disallowing mutation of types (without bumping some version) will allow users to spot changes quickly and feel more confident in using the definitions. I, at least, know I would this way about using the library if I didn’t follow (and partake in) development as closely as I am.
I think allowing code compatible changes in patch versions will allow us to bump minor versions at a slower rate, again allowing users to use the most updated versions of the definitions without any changes to their code (as switching to a newer patch version is automatic unless locked to a specific git hash or deps management lock-file).
I guess we will continue defining a type dependency only with the major and minor version. This means that as a bonus you can populate a void field of a type and all definitions using it will be usable with the newest version of the type without any changes (as only the patch version of the included type is changed).
I see a many small improvements of the approach i describe, but fewer and smaller disadvantages. I don’t think the way i descibe it is in essential for the greatness of uavcan, but I definitely think it’s one of those nice small things that helps.