Tagged releases?

[tsaubergine]

The last tagged release was on May 29, 2019 (1.0.12).

Could you please tag releases so that downstream package maintainers (such as myself) have a version to use rather than just pulling some random git hash from master?

[hamishwillee]

@julianoes @JonasVautherin Were you planning on adding the workflow to auto-tag releases anytime soon?

@tsaubergine We've been considering having a release every 2 weeks that will include a date stamp. The release wouldn't have any other semantics associated with it - i.e. we won't be tracking any additions to the release or changes. It's mostly a convenience so that we can supply a .deb file for the header - see https://github.com/mavlink/mavlink/pull/2037

[tsaubergine]

Any form of tagged release using semantic versioning would suffice for my needs. It's your choice as to how and how often you want to create those releases.

[hamishwillee]

@tsaubergine There is no intent to provide semantic versioning such as major.minor.patch. We're proposing to create automation to auto-tag the repo every two weeks with a date stamp that can be used as a release tag. At this point that is purely because .deb packaging requires such a release.

This may be extended to:

• include a generated .deb file
• trigger a matching tag release in the generated headers such as https://github.com/mavlink/c_library_v2

We don't want to do a semantic release at this time, because that implies certain things about what we're releasing - such as an update the the mavlink release number sent in generated messages. We don't want to iterate that unnecessarily because it's an 8 bit number, we don't need to iterate that because we maintain backwards compatibility.

Will a date stamped release of this kind be sufficient for your use case?