Semantic versioning for betaflight

[betaflight]

Semantic versioning for betaflight

[borisbstyle]

There is already semantic versioning 2.1.2...2.1.3....2.1.4.

Its pretty much the same like cleanflight. But you have a point with binaries.

[mikeller]

Semantic versioning stipulates:

`3. Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.

One possible workaround to keep within the best practices of semantic versioning is to use pre-releases if you are not sure what should be included in a release:

`9. A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

I am not trying to be picky here, my comment is based on the experience that sticking to the rules as they are postulated by semver helps a lot in dealing with the software release process.
e.g. if somebody reported an issue with betaflight 2.1.4, it would not be immediately obvious which of the multiple 2.1.4 releases this issue was occurring with.

[borisbstyle]

@mikeller
I actually used the pre-release github option. (except the last fix for blackbox_device)

The versioning has just started actually not long ago. The main goal of betaflight is to have very quick release of the beta version so the feedback can be gathered quickly. I will keep using pre-release option as I did with 2.1.4.