The following core ideas should be accommodated:
- It must be possible to introduce a breaking change (in the sense of wire compatibility) in one part of a namespace (by releasing a new major version or similar) without affecting other types in the same namespace. Different types serve different purposes, regardless of the fact that they are in the same namespace; a message related to flight control cannot be sensibly versioned synchronously with a file transfer service. The
@compatibledirective does not seem to solve this in any way because the release of a new major version requires all participating nodes to be aware of the new version of the namespace because nodes “must support different major versions separately”. Further:
The
@compatiblekeyword is a first class DSDL citizen with ability to “override” the outside versioning system.
This is a crutch. As you are descibing it, it is necessary to tie the solution to its problem domain because it doesn’t fit well on its own.
-
Breakage affecting the whole namespace without a very strong reason (such as releasing a new version of the entire protocol), scheduled or not, is unacceptable. That would undermine the long-term stability of the protocol; this is not a JS framework.
-
Concepts pertaining to code compatibility, code breakage, and code maintenance should not appear in the (normative parts of) specification, because they are too low-level and are not directly related to communication. I have introduced an alternative idea (that would lie out of the scope of the specification) where entire namespaces can be versioned purely for the sake of code compatibility and maintenance; if desired, we can go back to that.
I believe these were discussed at length in the past; specifically, the vices of global versioning are covered here: RFC: Separate versioning of data types · Issue #35 · OpenCyphal/public_regulated_data_types · GitHub, and why code compatibility is irrelevant was discussed here: The case for code compatibility - #4 by pavel.kirienko.
This proposal essentially re-raises the same questions, albeit posing them in a different way. Despite the new outlook, the core arguments remain unaffected and are still valid, I don’t think repeating the old discussions here makes much sense. It is clear that the new proposal contradicts the key ideas, and unless there is a sensible proposal to discard them without affecting the core design goals of the protocol, discussing this further does not make sense.
Observe that the old versioning proposal seems to fit the requirements well; unless the same can be shown about this one, we should go back to the old proposal.