We have decided this is not part of the public API so all that is needed is to change the annotation and post new RCs with that change with an update to release notes. It doesn’t matter if there was an incompatible change to the class made or not. A simple audience annotation mistake is taking disproportionate attention away from more important efforts.
If an annotation change to one class is the only update in a new RC you can have confidence in porting your votes from the last RC to the new one after confirming sums and signatures. For your consideration. > On May 25, 2019, at 12:37 PM, Peter Somogyi <psomo...@cloudera.com.invalid> > wrote: > > Unfortunately, that would require a new RC for 2.1.5 and I'm afraid > Guanghao already started the process for 2.0.0. > > On Sat, May 25, 2019 at 12:21 PM 张铎(Duo Zhang) <palomino...@gmail.com> > wrote: > >> A new issue can always solve the problem, I believe. I mean, revert the >> addendum from branch-2.2-, and open a new issue, which just changes the >> annotation for branch-2.2-, and commit the addendum again, with a new >> commit message. >> >> Peter Somogyi <psomo...@apache.org>于2019年5月25日 周六16:42写道： >> >>> On the 2.1.5RC0 testing I noticed that the release notes do not state >> that >>> LossyCounting was moved to IA.Private. This is tricky since the original >>> commit which introduced the incompatibility was not committed to >>> branch-2.1, only the addendum which only modified the IA annotation. For >>> 2.2.0 we have the same problem, however, 2.2.0 was added as fixed version >>> to HBASE-21991 even though only the addendum was committed to that branch >>> as well. >>> >>> Do we have any best practices for such a case? >>> >>> Thanks, >>> Peter >>> >>> On Fri, May 10, 2019 at 6:57 PM Sakthi <sakthivel.azh...@gmail.com> >> wrote: >>> >>>> Looks good to me. >>>> >>>> Sakthi >>>> >>>> On Fri, May 10, 2019 at 6:18 AM 张铎(Duo Zhang) <palomino...@gmail.com> >>>> wrote: >>>> >>>>> +1. >>>>> >>>>> Jan Hentschel <jan.hentsc...@ultratendency.com> 于2019年5月10日周五 >>> 下午9:08写道： >>>>> >>>>>> Also +1 for making it IA.Private. >>>>>> >>>>>> From: Peter Somogyi <psomo...@apache.org> >>>>>> Reply-To: "dev@hbase.apache.org" <dev@hbase.apache.org> >>>>>> Date: Friday, May 10, 2019 at 1:41 PM >>>>>> To: "dev@hbase.apache.org" <dev@hbase.apache.org> >>>>>> Subject: Re: [DISCUSS] Moving IA.Public class LossyCounting to >>>> IA.Private >>>>>> in all maintenance branches >>>>>> >>>>>> +1 on moving LossyCounting to IA.Private >>>>>> >>>>>> On Fri, May 10, 2019 at 7:54 AM Stack <st...@duboce.net<mailto: >>>>>> st...@duboce.net>> wrote: >>>>>> >>>>>> Looks good to me. >>>>>> S >>>>>> >>>>>> On Thu, May 9, 2019 at 7:02 PM Sean Busbey <bus...@apache.org >>> <mailto: >>>>>> bus...@apache.org>> wrote: >>>>>> >>>>>>> Hi folks! >>>>>>> >>>>>>> just a heads up that a few of us are planning to move a class out >>> of >>>>>>> the public API without a deprecation cycle. >>>>>>> >>>>>>> From the planned release note: >>>>>>> >>>>>>>> The class LossyCounting was unintentionally marked Public but >> was >>>>> never >>>>>>>> intended to be part of our public API. This oversight has been >>>>>> corrected >>>>>>>> and LossyCounting is now marked as Private and going forward >> may >>> be >>>>>>>> subject to additional breaking changes or removal without >> notice. >>>> If >>>>>> you >>>>>>>> have taken a dependency on this class we recommend cloning it >>>> locally >>>>>>> into >>>>>>>> your project before upgrading to this release. >>>>>>> >>>>>>> This class was came in via HBASE-19722 and was published in HBase >>>>>>> 1.4.6, 2.0.2, and 2.1.3 (and depending on RC timing might be in >>>>>>> 2.2.0). >>>>>>> >>>>>>> It will move to IA.Private as of 1.4.10, 1.5.0, 2.0.6, 2.1.5 and >>>> later >>>>>>> (maybe 2.2.1 depending on RC timing). The class already has >>>>>>> backwards-incompatible changes set to happen in upcoming releases >>>>>>> 1.4.10, 1.5.0, and 2.2.0. >>>>>>> >>>>>>> Please speak up sooner rather than later if you'll have a problem >>>>>>> voting on RCs that include this change, either here or on >>>> HBASE-21991. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>
