Versioning

We should think about a different versioning: http://semver.org/

This is also recommended by Github.

[nHirsenkorn]

The versioning definition is mostly suited for APIs, however we can adopt parts of it:

Major:

Incompatibility of code and recorded proto messages.
e.g. when the number of a field is changed.

Minor:

Compatibility to recorded files is remained, but Code is broken.
e.g. renaming of a field, without changing the field number.

Patch:

Compatibility of both recorded files and Code.
e.g. when adding a comment or ordering the messages / files in a different way.

Consider new names for major, minor and patch.

I would agree with this! I actually think that mayor, minor and patch fit quite well!
What's your oppinon @TimoHankeBMW or @SoykaDaimler

[Soyka-zz]

Sounds reasonable to me.

[TimoHankeBMW]

I think it's a good idea if the we adapt the wording to fit a message interface and specify compatibility behavior of sender / receiver communications and calling code over different versions.
Additionally, we should agree on a new developments on latest only policy that is implicitly enforced by the current versioning scheme, i.e. no new content (minor versions) are added to any but the most recent major version

/**
 * The interface version number.
 */
message InterfaceVersion
{
    // The field containing the version number. Should be left on default, not to be modified by sender.
    // Increments will happen as part of changes to the whole interface.
    optional uint32 major = 1 [default = 2];
    optional uint32 minor = 2 [default = 0];
    optional uint32 patch = 3 [default = 0];
}

Versioning

The version number is defined in InterfaceVersion::version_number in osi_common.proto as the field's default value.

Major:
A change of the major version results in an incompatibility of code and recorded proto messages.

• An existing field with a number changes its meaning
  optional double field = 1; -> repeated double field = 1;
  Changing the definition of units of a field
• Deleting a field and reusing the field number
• Changing the technology
  ProtoBuffer -> FlatBuffer

Minor:
A change of the minor version indicates remaining compatibility to previously recorded files. The code on the other hand needs fixing.

• Renaming of a field without changing the field number
• Changing the names of messages
• Adding a new field in a message without changing the numbering of other fields

Patch:
The compatibility of both recorded files and code remains.

• File or folder structure which does not affect including the code in other projects
• Changing or adding comments
• Clarification of text passages explaining the message content