Clarify Backward Compatibility

[Firionus]

Is your feature request related to a problem? Please describe.

Wikipedia defines backward compatibility like this:

A data format is said to be backward compatible with its predecessor if every message or file that is valid under the old format is still valid, retaining its meaning, under the new format.

Semantic Versioning is widely spread in the open source software community, for example on npm. One of its aspects is that breaking changes, i.e. non-backward compatible changes, are announced with an advance in the major version. For example, v19.3 would be fully backward compatible to v19.0 and v19.1.

GDTF so far has not declared anything about its backwards compatibility, but has broken it when moving from GDTF 1.0 to GDTF 1.1, e.g. moved DmxChannel Default to Channel Function. This breaks backward-compatibility because a GDTF 1.1 parser will not expect the Default in the DmxChannel and therefore error or not recognize the default.

Breaking backward compatibility with only a change in minor version is counter-intuitive when one comes from the background of semantic versioning.

Describe the solution you'd like

Adopt Semantic Versioning. If breaking changes are needed, make the next GDTF version 2. In that case, also clarify in the standard that Semantic Versioning is used and that breaking changes were made.

Describe alternatives you've considered

Clarify in the standard if the current GDTF version is backward compatible and if yes, to what prior versions. Keep the current naming scheme where breaking changes can be introduced in minor versions.

[petrvanekrobe]

Hi @Firionus ,

thank you for the feedback, at this point, SemVer has not been considered.