Short Summary: I see 6 informal +1s (including my own) for adopting Semver, and no -1s. Other points differ.
Longer Summary: Including additional strictness for deprecation documented in a major release does not have significant consensus and, in hindsight, probably doesn't really add much value. Semver does not bind us to a particular release cycle for major/minor/bugfix, only what we call it when we make certain changes. The basic Semver rules are sufficient. Including additional strictness for forward compatibility isn't necessary. Semver requires a minor version bump if new features are added to the API. So, this is redundant and not needed. Including the wire version is tough without a test framework, and maybe unnecessary, since the main concern about compatibility seems to be with applications needing to be modified to function with a newer client library, which contains the RPC code. If we ensure compatibility at the API, then users simply need to drop in the appropriate client jars for wire compatibility. This is probably sufficient. There seems to be some confusion about when and where these rules are applied. However, I believe we can go ahead and start adopting these rules from here on, without any issues. This doesn't hurt users, and only *adds* to the stability of the API, which we've already been striving for. It also doesn't bind us to a particular release cycle or deprecation duration. It only helps us determine what minimum version we should call something, when we do release. Upon adoption, the "master" branch version can be computed from the rules. If that computation requires a bump higher than what we are comfortable with, we can always ensure a greater level of compatibility than what currently exists, in order to avoid that bump, if we so choose. Adoption of these rules should help inform such discussions. Now, to be clear, it may be the case that the 1.5 and 1.6 maintenance branches already have introduced additional APIs that under Semver would have required a minor version bump. I'm not suggesting that we revert those changes, but by adopting the Semver, we can agree to avoid doing that from here on. Since 1.7 already adds additional features, by adopting Semver, we simply agree that the master branch should be called 2.0 if it is not backwards-compatible with 1.6.x, and 1.7.0 if it is. Adopting these rules helps inform that decision, but does not make that decision for us. Either way, that decision would be independent of adopting Semver today for all future releases. Incidentally, this answers the question of whether 2.0 can introduce "breaking" (removal of deprecations) changes, but it does not say that we must stop support for 1.x or release 2.0 on any particular timeline. Action: In the absence of further discussion, I think we should call a majority vote (tomorrow) to adopt Semver, so we can immediately start communicating better versioning semantics, and we can make progress with a concrete decision to help with release planning. The specific wording of the proposition I would suggest (please propose amendments here if you think it is unclear) would be: "Vote to adopt Semantic Versioning 2.0.0 (as described at https://semver.org) from this point forward, for all future releases, with the public API documented in the README." -- Christopher L Tubbs II http://gravatar.com/ctubbsii
