Add server versioning proposal

[bruth]

No description provided.

[caleblloyd]

I have not heard of a defect release before, but fix is common with breaking.feature.fix from Convential Commits, Semantic Release, and the prior art those are based on

I think any of the options that stray from SemVer are not a good idea. SemVer is heavily used in automation tools like Dependabot and such. While it might be nice to have a 4th option, such as release.breaking.feature.fix, there is just not much support for parsing and comparing those so it is guaranteed to break automation. Hijacking PreRelease tags or BuildInfo to indicate that this is a different, compatible Stable release would not be properly handled by automation either.

There is, of course the option of versioning JS APIs within the Server. K8s APIs are one example and applied to NATS could look something like core/v1, stream/v1, kv/v1beta1, and obj/v1alpha1. This would be a large undertaking for the server, however.

Another option could be to simply keep versioning things as they are, but document that minor releases in the nats-server may have major breaking changes in JetStream APIs, so read the release notes on those.

[ripienaar]

@bruth is this still something we would like to get in here? Else I'll close