Return-Path: X-Original-To: apmail-hbase-dev-archive@www.apache.org Delivered-To: apmail-hbase-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9A14F17653 for ; Fri, 24 Apr 2015 17:21:50 +0000 (UTC) Received: (qmail 34107 invoked by uid 500); 24 Apr 2015 17:21:50 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 34042 invoked by uid 500); 24 Apr 2015 17:21:49 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 34012 invoked by uid 99); 24 Apr 2015 17:21:49 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 Apr 2015 17:21:49 +0000 X-ASF-Spam-Status: No, hits=3.2 required=5.0 tests=HTML_MESSAGE,SPF_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: softfail (nike.apache.org: transitioning domain of saint.ack@gmail.com does not designate 54.76.25.247 as permitted sender) Received: from [54.76.25.247] (HELO mx1-eu-west.apache.org) (54.76.25.247) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 24 Apr 2015 17:21:21 +0000 Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 9571324E9B for ; Fri, 24 Apr 2015 17:21:19 +0000 (UTC) Received: by qkhg7 with SMTP id g7so34048803qkh.2 for ; Fri, 24 Apr 2015 10:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=uXTuF81OkdjdEji0f3vwQD+SWwF0MT4yODc4Rt26Mkc=; b=erPSaNDt5JfdMuXt7l5JAPJYLzJZvunNoM19yP/W+WVJ5VilJFvblwC7e55n1x0T5I daPZaHep3atIS8g82VaE2NRfoSK6Z+9WNC3jo8+1HPGVC/b/X6Zx41YAlx7/ZVNLb5yt /i6zSlcMMtgn5A61lvYJAddBDMPMrnx0YkCB4VCNagyRzC2rdWAtnJ5iT/n3l/W5VNV6 /lvjOMTjoiSHYQlbVZncfw57bj8n+qp1y2p8duZ7NCqRH9R+nOybaE0xqQPoNfZghXC2 Viv/OQqxIQMAS0YbKhH5AUc6g1Ft07FoS11JxHH1s/c/2J1zlFanrKLIvWCItKRIIN7j G51Q== MIME-Version: 1.0 X-Received: by 10.55.17.209 with SMTP id 78mr2089660qkr.18.1429896078657; Fri, 24 Apr 2015 10:21:18 -0700 (PDT) Sender: saint.ack@gmail.com Received: by 10.140.143.137 with HTTP; Fri, 24 Apr 2015 10:21:18 -0700 (PDT) In-Reply-To: <553A6D79.8030605@gmail.com> References: <5537D45D.3020207@gmail.com> <5537DBF5.6080204@gmail.com> <553A6D79.8030605@gmail.com> Date: Fri, 24 Apr 2015 10:21:18 -0700 X-Google-Sender-Auth: n5BuCN55tXwaRDB-iccqLAKRsfk Message-ID: Subject: Re: Clarifying interface evolution freedom in patch releases (was: Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2)) From: Stack To: HBase Dev List Content-Type: multipart/alternative; boundary=001a113ad022d58f2d05147b9f89 X-Virus-Checked: Checked by ClamAV on apache.org --001a113ad022d58f2d05147b9f89 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Apr 24, 2015 at 9:21 AM, Josh Elser wrote: > Cool, it seems that we have consensus. Let me try to give a patch since > you all were nice enough to entertain me with a good discussion on the > matter! > > https://issues.apache.org/jira/browse/HBASE-13554 > > > Thanks for filing the issue. Do we want to say SemVer in 2.0+? St.Ack > Enis S=C3=B6ztutar wrote: > >> +1 to "working toward semver". Is there any documentation that we would >> like to clarify in the book given this enlightenment? >> >> I would be in favor of going 2.6.0 and jackson upgrade in 1.1. >> >> Enis >> >> On Thu, Apr 23, 2015 at 5:34 PM, Nick Dimiduk wrote= : >> >> On Thu, Apr 23, 2015 at 4:13 PM, Stack wrote: >>> >>> Does this 'admission' help with the which-hadoop thread too? >>>> >>>> Right -- "working toward semver". >>> >>> Are we now at liberty to bump to 2.6 or 2.7 even for branch-1.1? I stil= l >>> have Karthik's offer to roll a 2.5.3 with the HDFS issue resolved. >>> >>> What about the jackson issue with 2.5 YARN runtime? >>> >>> Thanks Sean and Josh for being our community conscience on these issues= . >>> >>> Just want to make sure we're all on the same page (or find out if not)= . >>>> >>>>> On Thu, Apr 23, 2015 at 2:59 PM, Enis S=C3=B6ztutar >>>>> >>>> wrote: >>> >>>> Then let's get Andrew's proposal committed: >>>>>> >>>>>> + APIs available in a patch version will be available in all later >>>>>> + patch versions. However, new APIs may be added which will not be >>>>>> + available in earlier patch versions. >>>>>> >>>>>> I propose the following change to the "Client Binary compatibility" >>>>>> >>>>> section >>>>> >>>>>> of Section 11.1: >>>>>> >>>>>> - Old client code can run unchanged (no recompilation needed) agains= t >>>>>> >>>>> new >>>> >>>>> jars. >>>>>> + Client code written to APIs available in a given patch release >>>>>> + can run unchanged (no recompilation needed) against the new >>>>>> + jars of later patch versions. >>>>>> >>>>>> We can even claim that if you are not using new APIs, we are binary >>>>>> >>>>> compat >>>>> >>>>>> for downgrade. But you have to make sure that your code compiles wit= h >>>>>> >>>>> that >>>>> >>>>>> downgraded version. >>>>>> >>>>>> Enis >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Apr 23, 2015 at 2:04 PM, Sean Busbey >>>>>> >>>>> wrote: >>>>> >>>>>> I'm fine with us adding methods to public APIs in patch releases so >>>>>>> >>>>>> long >>>>> >>>>>> as >>>>>> >>>>>>> we stop claiming to follow semver. We can say we take the >>>>>>> >>>>>> principles >>> >>>> of >>>> >>>>> semver as inspiration. This would reflect the current state of the >>>>>>> >>>>>> world >>>>> >>>>>> WRT 1.0.1 and would still give us a reason keep the narrower >>>>>>> >>>>>> definition >>>> >>>>> of >>>>>> >>>>>>> "new features" in minor versions. >>>>>>> >>>>>>> >>>>>>> No longer claiming semver would also have the added benefit of >>>>>>> >>>>>> making >>> >>>> it >>>>> >>>>>> for me to easier to explain our compatibility promises to people. >>>>>>> >>>>>> Right >>>> >>>>> now >>>>>> >>>>>>> I have to explain the difference between the things that get proper >>>>>>> >>>>>> semver >>>>>> >>>>>>> treatment (e.g. public api, wire compat) and which things are >>>>>>> >>>>>> downgraded >>>>> >>>>>> to >>>>>> >>>>>>> breaking-on-minor (e.g. LimitedPrivate, binary compatibility). >>>>>>> >>>>>> Starting >>>> >>>>> with the context of "we like semver" will be easier than "we use >>>>>>> >>>>>> semver". >>>>> >>>>>> >>>>>>> Like Josh, my main concern is that we accurately advertise what >>>>>>> >>>>>> we're >>> >>>> doing. There are few things I've found more frustrating than being >>>>>>> >>>>>> an >>> >>>> end >>>>> >>>>>> user of a project that claims to follow semver without >>>>>>> >>>>>> understanding >>> >>>> the >>>>> >>>>>> burden that carries (and subsequently not meeting it). >>>>>>> >>>>>>> On Thu, Apr 23, 2015 at 3:48 PM, Stack wrote: >>>>>>> >>>>>>> I agree w/ the Enis characterization (so we need the callout on >>>>>>>> >>>>>>> semvar) >>>>> >>>>>> but >>>>>>> >>>>>>>> think we should practice what Seans says (patch is bug fixes >>>>>>>> >>>>>>> only). >>> >>>> St.Ack >>>>>>>> >>>>>>>> On Thu, Apr 23, 2015 at 1:31 PM, Sean Busbey< >>>>>>>> >>>>>>> busbey@cloudera.com> >>> >>>> wrote: >>>>>>> >>>>>>>> Why don't we just focus development after a minor release on >>>>>>>>> >>>>>>>> the >>> >>>> next >>>>> >>>>>> minor >>>>>>>> >>>>>>>>> release instead of the next patch release? >>>>>>>>> >>>>>>>>> We could limit backports to the patch releases to critical >>>>>>>>> >>>>>>>> bugs, >>> >>>> which >>>>>> >>>>>>> would cut down on how often someone has to deal with the pain >>>>>>>>> >>>>>>>> of >>> >>>> making >>>>>> >>>>>>> sure we don't add to public APIs. It also reduces the risk >>>>>>>>> >>>>>>>> someone >>>> >>>>> going >>>>>>> >>>>>>>> through an upgrade has, since there are fewer changes. >>>>>>>>> >>>>>>>>> If someone fixes a bug and doesn't want to do the work of >>>>>>>>> >>>>>>>> making >>> >>>> sure >>>>> >>>>>> it >>>>>>> >>>>>>>> doesn't add methods in a patch release, they just don't >>>>>>>>> >>>>>>>> backport >>> >>>> to >>>> >>>>> that >>>>>>> >>>>>>>> version and make a follow on e.g. "backport to 1.0.z" ticket. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Apr 23, 2015 at 1:50 PM, Enis S=C3=B6ztutar< >>>>>>>>> >>>>>>>> enis.soz@gmail.com >>>> >>>>> wrote: >>>>>>>> >>>>>>>>> +1 to the proposal. >>>>>>>>>> >>>>>>>>>> The problem is that we have a very big API surface especially >>>>>>>>>> >>>>>>>>> with >>>>> >>>>>> the >>>>>>> >>>>>>>> coprocessors included in the report. Even simple bug fixes >>>>>>>>>> >>>>>>>>> can >>> >>>> introduce >>>>>>>> >>>>>>>>> protected or public methods to base classes, which makes >>>>>>>>>> >>>>>>>>> patch >>> >>>> releases >>>>>>> >>>>>>>> very hard to maintain. I would not want to spend the effort >>>>>>>>>> >>>>>>>>> to >>> >>>> spend >>>>>> >>>>>>> tons >>>>>>>> >>>>>>>>> of time trying to make a patch not introduce new methods in >>>>>>>>>> >>>>>>>>> order >>>> >>>>> to >>>>>> >>>>>>> backport. That effort can be spent elsewhere IMO. >>>>>>>>>> >>>>>>>>>> Looking at the report >>>>>>>>>> >>>>>>>>>> >>>>> https://people.apache.org/~enis/1.0.0_1.0.1RC2_compat_report.html, >>>>> >>>>>> nothing >>>>>>>>> >>>>>>>>>> strikes me as "new functionality". Going from current 1.0.0 >>>>>>>>>> >>>>>>>>> to >>> >>>> 1.0.1RC2 >>>>>>> >>>>>>>> should actually be as you would expect from upgrading a patch >>>>>>>>>> >>>>>>>>> release. >>>>>>> >>>>>>>> Yes, adding new API in patch releases will make downgrading >>>>>>>>>> >>>>>>>>> harder, >>>>> >>>>>> but I >>>>>>>> >>>>>>>>> think that is an acceptable tradeoff. We can document that if >>>>>>>>>> >>>>>>>>> your >>>>> >>>>>> application compiles (meaning that you are not using new API) >>>>>>>>>> >>>>>>>>> with >>>>> >>>>>> 1.0.0, >>>>>>>> >>>>>>>>> then you can swap your jars in a binary compat manner. >>>>>>>>>> >>>>>>>>>> Enis >>>>>>>>>> >>>>>>>>>> On Thu, Apr 23, 2015 at 10:03 AM, Andrew Purtell< >>>>>>>>>> >>>>>>>>> apurtell@apache.org> >>>>>>> >>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Anyone disagree with the point of view put forward by Josh >>>>>>>>>>> >>>>>>>>>> and >>>> >>>>> Sean? >>>>>>> >>>>>>>> >>>>>>>>>>> On Wed, Apr 22, 2015 at 10:35 AM, Josh Elser< >>>>>>>>>>> >>>>>>>>>> josh.elser@gmail.com >>>>>> >>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Andy -- I understood your intent, but thanks for >>>>>>>>>>>> >>>>>>>>>>> clarifying. >>>> >>>>> (as >>>>>> >>>>>>> well >>>>>>>> >>>>>>>>> as >>>>>>>>>> >>>>>>>>>>> taking the time to break this discussion out in the first >>>>>>>>>>>> >>>>>>>>>>> place). I >>>>>>> >>>>>>>> agree >>>>>>>>>> >>>>>>>>>>> with your assessment. >>>>>>>>>>>> >>>>>>>>>>>> re: Sean's comments, if it wasn't clear by me asking in >>>>>>>>>>>> >>>>>>>>>>> the >>> >>>> first >>>>>> >>>>>>> place, >>>>>>>>>> >>>>>>>>>>> I >>>>>>>>>>> >>>>>>>>>>>> also think sticking as close as possible to semver's >>>>>>>>>>>> >>>>>>>>>>> rules >>> >>>> is >>>> >>>>> the >>>>>> >>>>>>> best >>>>>>>>> >>>>>>>>>> approach, although I'm getting the impression that there >>>>>>>>>>>> >>>>>>>>>>> have >>>> >>>>> been >>>>>>> >>>>>>>> some >>>>>>>>> >>>>>>>>>> previous reservations to doing so (especially by your >>>>>>>>>>>> >>>>>>>>>>> comment >>>> >>>>> about >>>>>>> >>>>>>>> backporting features if there is demand is). >>>>>>>>>>>> >>>>>>>>>>>> I've found adhering to the bug-fix release restrictions >>>>>>>>>>>> >>>>>>>>>>> can >>> >>>> be >>>>> >>>>>> a >>>>>> >>>>>>> very >>>>>>>> >>>>>>>>> painful and time-consuming task, so this is something to >>>>>>>>>>>> >>>>>>>>>>> get >>>> >>>>> a >>>>> >>>>>> representative sampling of those who do the work to make >>>>>>>>>>>> >>>>>>>>>>> sure >>>> >>>>> everyone >>>>>>>>> >>>>>>>>>> is >>>>>>>>>> >>>>>>>>>>> on board. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Sean Busbey wrote: >>>>>>>>>>>> >>>>>>>>>>>> I'd much rather we stick with the definitions used in >>>>>>>>>>>>> >>>>>>>>>>>> Semantic >>>>> >>>>>> Versioning. >>>>>>>>>>> >>>>>>>>>>>> Our use is already confusing enough given our matrix of >>>>>>>>>>>>> >>>>>>>>>>>> compatibilities >>>>>>>>>> >>>>>>>>>>> that don't get "major version for breaking" protections. >>>>>>>>>>>>> >>>>>>>>>>>>> We've previously discussed how we'll do additional minor >>>>>>>>>>>>> >>>>>>>>>>>> releases >>>>>>> >>>>>>>> when >>>>>>>>> >>>>>>>>>> there's sufficient interest in the new features present >>>>>>>>>>>>> >>>>>>>>>>>> there. >>>>> >>>>>> What's >>>>>>>>> >>>>>>>>>> building that demand if any backwards compatible change >>>>>>>>>>>>> >>>>>>>>>>>> can >>>> >>>>> go >>>>> >>>>>> back >>>>>>>> >>>>>>>>> into a >>>>>>>>>>> >>>>>>>>>>>> patch release? >>>>>>>>>>>>> >>>>>>>>>>>>> Would we have an easier time restraining ourselves if we >>>>>>>>>>>>> >>>>>>>>>>>> had a >>>>> >>>>>> regular >>>>>>>>> >>>>>>>>>> schedule planned around new minor versions? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Apr 22, 2015 at 12:03 PM, Josh Elser< >>>>>>>>>>>>> >>>>>>>>>>>> josh.elser@gmail.com >>>>>>> >>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> While I can understand the desire to want to add >>>>>>>>>>>>> >>>>>>>>>>>> things, >>> >>>> I >>>> >>>>> do >>>>> >>>>>> think >>>>>>>> >>>>>>>>> it >>>>>>>>>> >>>>>>>>>>> makes things harder for users to reliably write code >>>>>>>>>>>>>> >>>>>>>>>>>>> against >>>>> >>>>>> versions >>>>>>>>> >>>>>>>>>> of >>>>>>>>>>> >>>>>>>>>>>> HBase which (by their view) should be completely >>>>>>>>>>>>>> >>>>>>>>>>>>> compatible >>>> >>>>> with >>>>>>> >>>>>>>> one >>>>>>>>> >>>>>>>>>> another. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Take this extremely hypothetical situation: I'm new to >>>>>>>>>>>>>> >>>>>>>>>>>>> HBase >>>>> >>>>>> and >>>>>>> >>>>>>>> start >>>>>>>>>> >>>>>>>>>>> writing some code against HBase 1.0.1 which was just >>>>>>>>>>>>>> >>>>>>>>>>>>> deployed >>>>> >>>>>> at >>>>>>> >>>>>>>> my >>>>>>>> >>>>>>>>> $job. I >>>>>>>>>>>>>> don't _know_ what APIs are new, I just know what exists >>>>>>>>>>>>>> >>>>>>>>>>>>> and >>>> >>>>> treat >>>>>>> >>>>>>>> that >>>>>>>>>> >>>>>>>>>>> as >>>>>>>>>>> >>>>>>>>>>>> acceptable for me to be using. Meanwhile in production, >>>>>>>>>>>>>> >>>>>>>>>>>>> some >>>>> >>>>>> other >>>>>>>> >>>>>>>>> people >>>>>>>>>>> >>>>>>>>>>>> find a bug with HBase 1.0.1 and roll back to 1.0.0 >>>>>>>>>>>>>> >>>>>>>>>>>>> which >>> >>>> they >>>>> >>>>>> had >>>>>>> >>>>>>>> been >>>>>>>>>> >>>>>>>>>>> previously using. My reaction would be "of course my >>>>>>>>>>>>>> >>>>>>>>>>>>> code >>> >>>> should >>>>>>> >>>>>>>> work >>>>>>>>> >>>>>>>>>> with >>>>>>>>>>>>>> HBase 1.0.0, I only used the public API" when in fact >>>>>>>>>>>>>> >>>>>>>>>>>>> this >>>> >>>>> is >>>>> >>>>>> not >>>>>>> >>>>>>>> true. >>>>>>>>>> >>>>>>>>>>> Personally, I think it's a little bold to say semver is >>>>>>>>>>>>>> >>>>>>>>>>>>> even >>>>> >>>>>> in >>>>>> >>>>>>> use >>>>>>>> >>>>>>>>> if >>>>>>>>>> >>>>>>>>>>> this principal isn't being followed as it doesn't >>>>>>>>>>>>>> >>>>>>>>>>>>> follow >>> >>>> at >>>> >>>>> all >>>>>> >>>>>>> with >>>>>>>>> >>>>>>>>>> my >>>>>>>>>> >>>>>>>>>>> understanding on the guarantees defined by semver for >>>>>>>>>>>>>> >>>>>>>>>>>>> bug-fix >>>>> >>>>>> releases. >>>>>>>>>> >>>>>>>>>>> That being said, if the intent *is* to allow ourselves >>>>>>>>>>>>>> >>>>>>>>>>>>> to >>> >>>> make >>>>>> >>>>>>> these >>>>>>>>> >>>>>>>>>> sorts >>>>>>>>>>>>>> of changes, I just think some sort of disclaimer should >>>>>>>>>>>>>> >>>>>>>>>>>>> be >>>> >>>>> present: >>>>>>>> >>>>>>>>> - HBase uses Semantic Versioning for its release >>>>>>>>>>>>>> >>>>>>>>>>>>> versioning >>>> >>>>> + HBase uses Semantic Versioning for its release >>>>>>>>>>>>>> >>>>>>>>>>>>> versioning >>>> >>>>> with >>>>>>> >>>>>>>> a >>>>>>>> >>>>>>>>> caveat >>>>>>>>>>> >>>>>>>>>>>> that methods and members might be added in newer >>>>>>>>>>>>>> >>>>>>>>>>>>> bug-fix >>> >>>> releases >>>>>>> >>>>>>>> that >>>>>>>>>> >>>>>>>>>>> were >>>>>>>>>>>>>> not present in the previous bug-fix release. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Andrew Purtell wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> [Subject changed] >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Apr 21, 2015 at 8:47 PM, Josh Elser< >>>>>>>>>>>>>>> >>>>>>>>>>>>>> josh.elser@gmail.com> >>>>>>>> >>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I was a little surprised when I noticed method >>>>>>>>>>>>>>> >>>>>>>>>>>>>> additions >>>> >>>>> to >>>>>> >>>>>>> InterfaceAudience.Public annotated classes. This >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> means >>> >>>> that a >>>>>> >>>>>>> user >>>>>>>>> >>>>>>>>>> could >>>>>>>>>>>>>>>> write code against 1.0.1 that would not work against >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1.0.0 >>>>> >>>>>> which >>>>>>>> >>>>>>>>> seems >>>>>>>>>>> >>>>>>>>>>>> undesirable for a bugfix release. I read over the >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> book >>> >>>> section >>>>>>> >>>>>>>> on >>>>>>>> >>>>>>>>> compatibility and didn't see this addressed, so I >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> thought >>>> >>>>> I'd >>>>>> >>>>>>> ask. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>>> Let's clarify this. It's not the first time this >>>>>>>>>>>>>>> >>>>>>>>>>>>>> question >>>> >>>>> has >>>>>> >>>>>>> been >>>>>>>> >>>>>>>>> asked. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> To get things moving: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I propose the following addition to the "Client API >>>>>>>>>>>>>>> >>>>>>>>>>>>>> compatibility" >>>>>>>> >>>>>>>>> section >>>>>>>>>>>>>>> of Section 11.1: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> + APIs available in a patch version will be available >>>>>>>>>>>>>>> >>>>>>>>>>>>>> in >>> >>>> all >>>>> >>>>>> later >>>>>>>> >>>>>>>>> + patch versions. However, new APIs may be added which >>>>>>>>>>>>>>> >>>>>>>>>>>>>> will >>>>> >>>>>> not >>>>>>> >>>>>>>> be >>>>>>>> >>>>>>>>> + available in earlier patch versions. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I propose the following change to the "Client Binary >>>>>>>>>>>>>>> >>>>>>>>>>>>>> compatibility" >>>>>>>>> >>>>>>>>>> section >>>>>>>>>>>>>>> of Section 11.1: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Old client code can run unchanged (no recompilation >>>>>>>>>>>>>>> >>>>>>>>>>>>>> needed) >>>>>> >>>>>>> against >>>>>>>>>> >>>>>>>>>>> new >>>>>>>>>>>>>>> jars. >>>>>>>>>>>>>>> + Client code written to APIs available in a given >>>>>>>>>>>>>>> >>>>>>>>>>>>>> patch >>> >>>> release >>>>>>> >>>>>>>> + can run unchanged (no recompilation needed) against >>>>>>>>>>>>>>> >>>>>>>>>>>>>> the >>>> >>>>> new >>>>>> >>>>>>> + jars of later patch versions. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What do you think? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If these changes are (mostly) ok, then this clarifies >>>>>>>>>>>>>>> >>>>>>>>>>>>>> in >>> >>>> one >>>>> >>>>>> direction. >>>>>>>>>>> >>>>>>>>>>>> If these changes are not acceptable, I will propose >>>>>>>>>>>>>>> >>>>>>>>>>>>>> edits >>>> >>>>> that >>>>>> >>>>>>> clarify >>>>>>>>>> >>>>>>>>>>> toward the opposite meaning. =E2=80=8B >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >> --001a113ad022d58f2d05147b9f89--