Ahh.. if I had mentioned it earlier, there wouldn't have been any confusion.
So the thing is, earlier patches (up to v6) are deleting the functions which take byte[] or String as argument. These are like 15 or so 'useless' functions and I believe it's okay to delete them. Later I updated the patch (v7-v8) to mark them deprecated (instead of deleting) to decouple that jira from discussion [1] @Andrew: which patch did you look at? Can you please confirm your take on this. Thanks. [1] https://issues.apache.org/jira/browse/HBASE-14769?focusedCommentId=15032734&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15032734 On Wed, Dec 2, 2015 at 5:32 PM, Andrew Purtell <andrew.purt...@gmail.com> wrote: > Ok, so no annotation change then. I looked at HBASE-14769. Change there > seems fine. > > > > On Dec 2, 2015, at 5:03 PM, Apekshit Sharma <a...@cloudera.com> wrote: > > > > In this particular case, we are deleting functions in HBaseAdmin which > take > > byte[] or String as argument. > > HBASE-14769 > > > > On Wed, Dec 2, 2015 at 4:56 PM, Andrew Purtell <andrew.purt...@gmail.com > > > > wrote: > > > >> We also might want to fix the annotation. Like Stack said it depends on > >> the particulars. I suggest filing a JIRA. > >> > >>> On Dec 2, 2015, at 4:36 PM, Stack <st...@duboce.net> wrote: > >>> > >>> Appy makes a pretty good argument. > >>> > >>> What in particular are we discussing Ashish? > >>> > >>> Thanks, > >>> St.Ack > >>> > >>>> On Wed, Dec 2, 2015 at 3:49 PM, Apekshit Sharma <a...@cloudera.com> > >> wrote: > >>>> > >>>> I think it should be okay to remove them. When I imagine myself on > other > >>>> side, a dev using client api of Foo project, and I see a class > returning > >>>> reference to an internal class, I would not trust that function. If I > >>>> really need something from returned ref, I'd probably use it, and if > it > >>>> goes away tomorrow, i'd probably curse it too, but I can't complain > >> since > >>>> it's not anything I trusted to being with. > >>>> > >>>> Now thinking as dev: > >>>> Given that documentation explicitly states that functions can > disappear > >>>> from private class, and nothing about transitiveness, I believe we can > >>>> remove functions from private class A. > >>>> > >>>> > >>>>> On Thu, Nov 26, 2015 at 7:10 AM, Ted Yu <yuzhih...@gmail.com> wrote: > >>>>> > >>>>> bq. we should not remove it directly > >>>>> > >>>>> My understanding is the same. > >>>>> > >>>>> Cheers > >>>>> > >>>>> On Wed, Nov 25, 2015 at 10:22 PM, ashish singhi < > >>>> ashish.sin...@huawei.com> > >>>>> wrote: > >>>>> > >>>>>> Hello to all. > >>>>>> > >>>>>> I know that we can safely remove any APIs from a > >>>>> InterfaceAudience.Private > >>>>>> class and the same is described in the HBase book. > >>>>>> > >>>>>> Now consider a case (I did not find this mentioned in our semvar), > >>>>>> There is a class 'A' with InterfaceAudience.Private and class 'B' > with > >>>>>> InterfaceAudience.Public and then there is a public API in class 'B' > >>>>> which > >>>>>> returns an instance of class 'A'. (We missed to mark the public > method > >>>> in > >>>>>> class 'B' as deprecated when we marked the class 'A' as > >>>>>> InterfaceAudience.Private). > >>>>>> > >>>>>> Now the question is, can we remove the public APIs from class 'A' > >>>> without > >>>>>> marking them deprecated ? > >>>>>> > >>>>>> I think we should not remove it directly, it will break the users > >> using > >>>>>> these(removed) public methods from class 'A'. > >>>>>> P.S: This point came up in HBASE-14769. > >>>>>> > >>>>>> Regards, > >>>>>> Ashish Singhi > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> Regards > >>>> > >>>> Apekshit Sharma | Software Engineer, Cloudera | Palo Alto, California > | > >>>> 650-963-6311 > > > > > > > > -- > > > > Regards > > > > Apekshit Sharma | Software Engineer, Cloudera | Palo Alto, California | > > 650-963-6311 > -- Regards Apekshit Sharma | Software Engineer, Cloudera | Palo Alto, California | 650-963-6311
