Simplify release version decisions by following semver compatible comver

[owais]

Personally I really like comver over semver. It is governed by three simple rules:

1. If the change you're making is backward compatible, bump the minor version.
2. If the change you're making is backward incompatible, bump the major version.
3. For semver compatibility, never bump patch version and always keep it at 0.

This is compatible with semver so it'll not break anything or cause surprises for end users who expect semver. On the other hand, it'll make life a bit easier for maintainers and users (if we advertise we follow comver).

Details: https://gitlab.com/staltz/comver

[pellared]

I do not have a strong opinion. I would simply suggest bumping minor instead of patch in case there is ANY doubt.

I do not have any problem if any of our libraries never bump patch (it is SemVer compatible).

[flands]

Not a strong opinion, but some thoughts:

• OTel uses semver -- consistency is good
• Patch version can be very helpful as we deprecate / move to next major / etc -- think security fixes

Here is an example for Smart Agent: https://github.com/signalfx/signalfx-agent/releases/tag/v5.10.2.

Given we are close to 1.0, I would propose we keep semver and revisit later.

[owais]

Re-considering later sounds good to me.

OTel uses semver -- consistency is good

comver is semver compatible so we'd not be doing anything incompatible with otel.

Patch version can be very helpful as we deprecate / move to next major / etc -- think security fixes

Couldn't it be a minor release? As a consumer, do you expect me to treat patch vs minor versions different? I'm trying to understand in what cases would we want a patch version instead of minor and why would it be better than minor.

Feel free to ignore and come back later post 1.0 :)