Document grpc-go versioning strategy

[redbaron]

As explained in #1392 (comment) grpc-go doesn't follow semantic versioning conventions, even if package naming seems like so.

API breakage is fine, it is unavoidable and should be done for a greater good. Communicating it to library users is a different question. Most projects adopted semantic versioning to communicate these changes, Grpc choose not to. If so, then maybe consider option changing version schema to be explicitly not compatible with semenatic versioning?

Something like GRPCPROTOCOL: semver? So current version would be 1:1.6.0

I don't know what effect it would have on tooling,but if these versions wont break things like dep or glide, then maybe it is a way to go?

[dfawley]

The overall gRPC team dictates our versioning system (frequency and numbering), and it is not based on semantic versioning. I think a fair request would be for us to document our versioning strategy.