+1 On Dec 8, 2014 6:22 PM, "Christopher" <[email protected]> wrote:
> 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 >
