I agree that the current approach of automatic selection of the newest minor version is flawed. I was quite sure that we discussed this earlier and seemingly reached an agreement, but I can’t find that discussion now. Could you please change that in the DSDL chapter, seeing as you are currently working on it? I will update PyDSDL to always require both versions.
Rest of the argument still doesn’t make much sense to me.
Allowing automatic patch version selection for nested types would defeat the purpose of the patch version for the enclosing type. The problem I talked about in my previous message when a new data type with a newer minor version is introduced still stands, except that instead of the minor version it would affect the patch version.
The example of Cargo/PyPI does not seem to contradict the current arrangement. When you, say, modify a source file for your program, you don’t keep the old version around in the next git commit. Instead, it gets overwritten, and the older version will be stored in the git log. When a release-worthy state is reached, the released version is tagged and uploaded into a package repository like Cargo/PyPI, where it remains accessible forever. Same thing is attainable with DSDL at the namespace level, along with the possibility of using an external package repository, if desired.
It is true that there is some argument to be made against versioning of entire root namespaces as opposed to individual types within them: this approach couples versioning processes of possibly unrelated types, requiring the application designer to pay attention to all used types with every update, even those that did not require it. With the strong guarantees provided by the minor version, however, the amount of extra workload will be negligible, so I don’t consider this to be an issue.
My counterexample was poorly thought out, sorry. What I wanted to imply is that the additional guarantees provided by the patch version would be as weak as the risks introduced by non-validated compilers or bit-flipping DRAM. The memory bugs in Rust do not seem to be relevant here, because the Rust safety guarantees are built on top of a strong framework of enforceable rules and principles, whereas in the case of DSDL versioning, you have to trust that the existing definitions are maintained in a particular way, the only change introduced by the patch version is that the “particular way” is changed from “allowing only whitespace and comment changes” to “allowing no changes at all”; the base foundation (the source version control system) remains the same.
I understand the argument in favor of immutability, but I can’t see how strong per-data-type immutability guarantees, as opposed to per-namespace immutability guarantees, are helpful. Data types can have implicit inter-dependencies and coupling that cannot be expressed in terms of DSDL (at least, not currently). There can be micro-protocols built on top of several types that have no DSDL dependencies between each other, and hence the versioning system would not know about them; for example, consider the types defined under uavcan.file, uavcan.internet.udp, or uavcan.pnp. Locking down one type down to perfect immutability while possibly allowing others to differ or new ones to appear may somewhat undermine the usefulness of the guarantees, requiring the developer to re-evaluate the entirety of the namespace every time any member of it is changed.