Yes, that seems like a correct interpretation. However, to be clear, I do not expect 1.7.0 will be ready before a new client API is added.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, Dec 8, 2014 at 6:54 PM, John Vines <[email protected]> wrote: > Just to make sure I'm understanding this before we get into another vote > thread kerfluffle, if we adopt semver in 1.7.0, include a new client api in > 1.7.0, deprecate the old api in 1.7.0, then semver would allow (but not > require) removing the deprecated api in 2.0.0, correct? > > On Mon, Dec 8, 2014 at 6:21 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 > > >
