Protocol Versioning
Last updated
Was this helpful?
Last updated
Was this helpful?
The CommsDSL provides a way to specify version of the binary protocol by using version property of the element.
Other elements, such as or allow specification of version they were introduced by using sinceVersion property. It is also possible to provide an information about version since which the element has been deprecated using deprecated property. Usage of deprecated property is just an indication for developers that the element should not be used any more. The code generator may introduce this information as a comment in the generated code. However, it does NOT remove a deprecated from being serialized to preserve backward compatibility of the protocol. If the protocol definition does require removal of the deprecated field from being serialized, the deprecated property must be supplemented with removed property.
For example:
In the example above the field F2 was introduced in version 2. The field F3 was introduced in version 3, but deprecated and removed in version 4.
All these version numbers in the schema definition allow generation of proper version checks and correct code for protocols that communicate their version in their or selected messages. Please refer to chapter for more details on the subject.
For all other protocols that don't report their version and/or don't care about backward compatibility, the version information in the schema just serves as documentation. The code generator must ignore the version information when generating code for such protocols. The code generator may also allow generation of the code for a specific version and take provided version information on determining whether specific field exists for a particular version.