Clarify the MAVLink release process

[hamishwillee]

The "release story" for MAVLink is confusing for users because there are multiple things that can change

• source code for generators (in mavlink/mavlink and ArduPilot/pymavlink repos), and these have different release cycle and numbering from each other and from messgaes
• built libraries - e.g. for C and Pymavlink
• MAVLink version - 1 and 2
• MAVLink subversion - from messages.

Action is to define a process and/or clear story on how releases happen and how they sync (or not) with each other.

Kicked off from - #1141

[BazookaJoe1900]

@hamishwillee, For PX4 firmware,
How about generating the code during compilation time? not using the c_library.
anyway the "real" source is the XML+generator. both can be on the source of the PX4 (as submodules).

[hamishwillee]

@BazookaJoe1900 Re #1149 (comment) thanks, but that is out of scope for this discussion (it is PX4 specific and MAVLink is flight stack agnostic) - and I do not believe it solves the problem.

Ultimately the release process discussion fits around "what specific services, messages and versions of services and messages are supported by a particular communication partner. It is likely that even a release process will not necessarily solve this, but it may be part of the story.

[jarednm]

Along these lines, the Mavlink docs state:

The current MAVLink version is 2.3. The minor version numbers (after the dot) range from 1-255

But I cannot find anywhere that states:

• How version 2.3 is different from 2.2 or even 2.0.
• When and how minor releases are issued.

[hamishwillee]

@jarednm There is no formal release process and no documentation on the differences between the minor releases (yes, there should be).

We are pretty careful about compatibility. Most releases only make compatible changes (e.g. add extension fields). If we can't do that then we add new messages and deprecate the old ones - so the generated libraries still work.

There are several reasons for this. Firstly with only 8 bits for the version, if we made regular breaking changes we would already have run out of options. Secondly, we have lots of systems that rarely update firmware.

In addition, the problem is not just "what is supported in the file", but "what is supported by the system implementing it". If we solve this problem then the version of the file is less important.

We're working on a number of other techniques for this, including being able to query for what version of a service (e.g. parameter protocol) is supported and queries on what mission items etc are supported.

We will also periodically still be updating that minor release number, for example we hope to do a big cleanup of messages that have never been implemented. I expect we will do a reasonable job of documenting that change.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[hamishwillee]

Would like to clarify how releases kind of work (or dont) at some point

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.