There are several serious issues with this proposal, probably the most important one is that it flips the solution upside down, pushing the utterly important matter of wire compatibility (which is semantic compatibility and bit compatibility) to the background (via @compatible) while moving the far less important feature of code compatibility at the forefront. This is probably due to the implied underlying assumption that the application’s own code and its data types are to be versioned, released, and maintained in more or less the same way. This may be the case in deeply isolated ecosystems, but anywhere else this is not true. Data types represent carefully designed interfaces between different well-encapsulated computing systems; the interfaced computing systems are extremely unlikely to be maintained under synchronous release cycles, and as such, the release cycle of involved data types would be dictated by the least frequently updated computing system in the application (more on this: The case for code compatibility) which implies that compared to general-purpose embedded applications, data types are to be almost unchanging by design. If one needs to update their data types as frequently as the application itself, the data types are probably poorly designed (notice that the same could be said about software interfaces in general).
Another important issue is that this proposal makes simultaneous use of data types under different major versions unnecessarily difficult, and complicates static analysis. If one wanted to use several major versions of a data type in the same application, they would have to include several versions of the namespace. Since each namespace version is an isolated system, it would be difficult (although not impossible) to ensure that the definitions available in all of them do not conflict with each other. For example, a particularly troubling case is when a fixed ID of a data type defined in one version of the namespace is used for an incompatible definition of the same data type in a newer version. Admittedly, this is resolvable, but it just adds extra complexity for no good cause.
As we discussed at the last call, the specification cannot be dependent on any particular version control system, code hosting service, or any external infrastructure unless such infrastructure is exceptionally stable (i.e., as far as external infrastructures go, it is safe to rely on the English language or world wide web, because these things are not going away in the foreseeable future; whereas the long-term future of git, Github, or the Sami language is questionable). The specification also should not concern itself with trifling matters of access management, approval process, and all that related bureaucracy.
This is a significant departure from our current (i.e., old, the other one, not this one) draft proposal. For the benefit of other readers, I should clarify that it is mostly motivated by the problem of micro-protocols, which was first mentioned the old thread. The idea is that the current (old) proposal lacks adequate means of expressing semantic interdependency between different data types; currently, data types can express dependency only unidirectionally and only through composition: if A contains a field of type B (possibly indirectly), then A is dependent on B (possibly indirectly). What is missing is that A may not even mention B anywhere in its definition, while being semantically dependent on it; likewise, if A is a composition that contains B, it does not necessarily mean that B can’t be semantically dependent on A. There are several cases in the WIP standard data type set where the problem can be observed; yet I don’t think that it is severe enough to warrant immediate intervention. Several solutions can be discussed; the most obvious that come to mind are requiring that all interdependent types share the same major version (this implies that some data types may need to have their major version bumped while retaining semantic and bit compatibility), and adding special directives that fill the need for an explicit dependency declaration mechanism (like @depends foo.Bar, baz.*). I want to push back on that and release v1.0 without any such logic in place since it can be safely added retroactively. Doing that now not only delays the release (it’s no easy feature, and we will probably spend a few more months going back and forth unless we met in Tallinn/Trondheim/elsewhere for a day), it is also risky since we don’t yet have any experience working with the versioning system we designed.
Last but not least, the new proposal just doesn’t seem to map on the problem domain as well as the old one. Data types are more or less atomic interfaces (to some extent), even when they are used within micro-protocols. One should be prepared that any given non-isolated ecosystem may have dozens of nodes from different suppliers all using different data types or different versions of same types; this enforces a certain fragmented variety of the versioning problem that can’t be mapped well to the new proposal that assumes that namespaces or data type sets are inherently atomic.
Now, that said, I don’t really have anything against the general idea of root namespace versioning as long as it is done on top of the old per-type versioning solution and it is not mandated in any way in the specification (except probably in non-normative sections, but even that is probably unnecessary). This can be done trivially using standard principles of semver, and the protocol does not (and must not) care about it. I mentioned this approach in the old thread. It simply means that we can tag certain commits in the DSDL repo as “releases”.
Overall, I suggest we go back to the old arrangement.