Hello,
Is there a prescribed approach to FIX SBE versioning to communicate extensible and breaking changes differently? I’m referring to Sec. 5.2 of the FIXSBE Version 2 RC2 document. In general, versioning is specified as an integer field that keeps incrementing. In such approach, how would an endpoint identify automatically whether the received messages are forward / backward compatible with the template version used by the codec. Is automatic identification of breaking changes not intended, or, am I missing something here?
@thaya, a message template may only be extended if it meets the criteria for compatibility listed in section 5. If there is a breaking change, the designer of the message schema has the responsibility to create a new template and publish it to all consumers. In the words of the spec, “Changes that break those constraints require consumers to update to the current schema used by publishers.” Since no breaking changes should be published with the same template ID, the receiver ordinarily has no need to automatically detect such conditions. To do otherwise would be considered a protocol violation. Of course, when large changes are made to a message schema, the publisher may supplement the schema with out-of-band explanatory material.
Are we saying that the direction is not to increment version numbers for extensible changes?
The way I understood was; regardless of a change being extensible or not, the schema version should be incremented every time a change is done for the “since version” attribute to discriminate old and new fields for forward compatibility to work. Am I missing something here please?
No, I did not intend to imply that version number shouldn’t be incremented. To recap, it is the schema publisher’s responsibility to determine whether an extension conforms to the constraints. If so, the template may be extended and the schema is published with incremented version number. On the other hand, if there is a breaking change, a new template must be created, and assuming the other templates in the schema are still valid, the schema version is also incremented.
In some cases an old template may be still be accepted during a period of transition. The old template should be marked deprecated, and documentation should inform users that the new template is a replacement.