The Lab

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from this space and version 1.5.40

Table of Contents

Major/Minor Version

Different versions of the Whisperer SBE schema are identified via the version attribute of the <messageSchema> root element, e.g. version="18655".  This version applies to the schema as a whole, not to individual elements and is sent in the message header so the client can determine which version of the message schema was used to encode the message. The schema version number encodes a major.minor version scheme where the individual components are obtainable via the following bash one-liners:

Code Block
   Major=$((version >> 9))  # breaking changes
   Minor=$((version & 511)) # incremental changes

Major - Breaking Changes

Warning
titleBreaking Changes

In order to maintain consistent message normalisation standards, MarketFactory will occasionally have need to make schema changes that break backward compatibility rules. Typically these will be planned releases, with long lead-times.

In such circumstances, the client will be provided with detailed information relating to these changes in Pending Client System Impacts and may need to update to the current Whisperer schema.

Changes in the major version represent a breaking change that will require users of previous schema versions to make code changes.Typically, these will be of a straightforward house-keeping nature, including:

  • Removal of deprecated messages and components (impacting message layout), datatypes and enumeration values.
  • Reordering of message components.
  • Changing wire representations of individual fields (e.g. String lengths).
  • Renaming of fields, enumeration values and messages (typically semantic types and wire values will remain unchanged). 

Minor - Incremental Changes

The SBE protocol standard allows for a degree of backward compatibility via Template Extension rules, to allow message consumers to be using older versions of the message schema than message publishers, and vice versa. The following sections outline the rules and logic required to ensure that backward compatibility problems are reduced to a minimum.

Obviously this backward compatibility is only of use if the added types, fields, or messages are not actually required for the implemented business processes. If the new features are required then the client must of course implement the necessary changes to support the new schema in full.

...

The following Template Extensionrules ensure backward compatibility:

...

Any message template that has changed in an incompatible way may be assigned a new template "id" attribute. However:

...

titleBreaking Changes

In order to maintain consistent message normalisation standards, MarketFactory will occasionally have need to make schema changes that break backward compatibility rules.

...

.

...

...

Version

...

Different versions of the Whisperer SBE schema are identified via the version attribute of the <messageSchema> root element, e.g. version="18367".  This version applies to the schema as a whole, not to individual elements and is sent in the message header so the client can determine which version of the message schema was used to encode the message.

The version number is in fact an Epoch date value, and can be converted into a calendar date by use of the following bash one-liner:

Code Block
echo $(date -d @$((version*86400)) +%F)

Version Compatibility Scenarios

The message decoder compares the schema version in a received message header to the version that the decoder was built with.

...

  • sinceVersion - Documents the version of a schema in which a type an element was added
  • deprecated - Documents the version of a schema in which a type an element was deprecated. Updated applications should not publish deprecated messages or values, but declarations may remain in the message schema during a staged migration to replacement message layouts.

...