Ack! My clarity failed: I *DO* expect 1.7.0 to be ready before a new client API is added.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, Dec 8, 2014 at 7:00 PM, Christopher <[email protected]> wrote: > 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 >> > >> > >
