DDSXTY12 — A @Version annotation shall be added

The X-Types specification does not provide any way of attaching version information to topic types. This is unfortunate as this information is quite essential to help debug running systems by identifying which version of the information model each element is working with.

As a consequence a new annotation @Version should be added for topic types. A possible definition of this annotation is shown below:

@Annotation
local interface Version

;

Add a @Version annotation

The RTF discussed what the purpose of the @version annotation was and it was determined the value comes from situations were there is a single authority/governance body that controls the type system.

In this situation, having some "version" annotation that can distinguish intentional changes/evolutions of a type versus some error can be a useful "system integration" aid. The idea is that each time someone modifies a type in a system it would tag it with some "application meaningful" (it could be a version number like major.minor.revision, or a date, or some other label). Then duding deployment when compatibility of types between DataWriter and DataReaders is examined this additional tag is available.

Type compatibility is determined using the "assignability rules" this done independent of the version number/tag. In addition to this:

• If the tags are different (or absent in one side) then there no additional things to do.
• If the tags are the same but the types are not identical, then this could trigger some warning/errors coming via DDS status/listeners. The fact that the same version tag was used indicated the application was trying to use the same version of the types for that writer/reader. The fact that they did not match indicates that there was some process error and somehow the two applications ended up with different types.

There was agreement in the RTF that this was a useful feature, but leaving the version as an "unstructured" string. Without adding version numbers, dates, etc. It just needs to be checked for equality and it is up to the people defining the type system to create their own convention.

The RTF discussed whether it made change to have a different behavior at the DDS level. The most "obvious" one suggested was to force "mismatched type" error for types that were assignable/compatible but not identical if their version tag was the same. Idea is similar to the compiler option of "error on warnings". Make it harder for people to deploy systems with this type of inconsistency. At the same time it was agreed that most of the benefit of this feature could be obtained using a tool that would monitor the types and detect that inconsistency. And this would not require a forceful change in matching behavior.

The RTF agreed to add the @version annotation and describe the intended use, but not force any implementation behaviors. It would be up to vendors to provide tools around this or support a "error" behavior on those types with identical version and non-identical structure... If in the future the vendors determine that the "fail" behavior is important to support and must be made interoperable then it can easily be added without breaking deployed system