Skip to content
cabo edited this page May 19, 2022 · 8 revisions

Collecting learnings from versioning (data model evolution)

Slides from WISHI calls:

Reasons for versioning

Three different reasons that may bring the need to version data models:

  • Evolution of the needs for the models. For example, a new feature is needed for an existing model.
  • Errors in the original published models. These can be of different category: from simple typos in descriptions to features that are not good design / efficient (e.g., using string format for numeric values when a numeric type exists), to broken models (e.g., two qualities give conflicting information)
  • Need to merge models from different sources

Compatibility

A lot of confusion emanates from the terms "backward" and "forward" compatibility. The Wikipedia articles propose:

  • backward compatibility: old producer, old data -- work with -- new consumer
  • forward compatibility: new producer, new data -- work with -- old consumer

Of course, the definition of "work with" needs work, too.

Interoperability

See compatibility. But note that Interoperability is not always desired -- the main reason to include a version number in some data or a protocol execution is to prevent false interoperability, i.e., data consumption that misinterprets data as under a different version of the specification that governs the data semantics.

Versioning of software, protocols, ...

The reasons for versioning software are fundamentally different from those for versioning protocols (interfaces).

A software version can implement multiple protocol versions, in order to satisfy some compatibility requirements.

Software progression often is linear; protocol progression rarely is (unless Procrustes forces it to be).

Note that there is also revision of the documents describing protocols or documents; revision can happen without protocols (intentionally) changing. Sometimes a reference to a specific revision is needed (e.g., to capture a specific revision of a copyright statement).