Sorry to dig up this old thread. I've also just commented on < https://issues.apache.org/jira/browse/HBASE-19746>
The book says: > MAJOR version when you make incompatible API changes, So do we really need to keep BC between major versions? How else would we ever add new methods to interfaces without having default implementations? On Fri, Dec 15, 2017 at 2:26 PM, Anoop John <anoop.hb...@gmail.com> wrote: > Good point Chia. Interfaces like Region, TableDesc are not meant for > own impl by the users or CP users. These are just read only > interfaces. Would be best if we can have a way to say so. We > should distinguish an exposed interface/class to say whether this is > just read only or allowed to be extended. > > In another jira we have a discuss abt the own impl of Cell being added > to Put or not.. We are facing some issues if user do so.. So if we > have this new annotation and mark clearly that Cell is just read only > that will be a better way than just saying in javadoc. :-) But then > we have APIs which takes interfaces like Cell/TableDescriptor as > param. So some way we should say how that can be done.. We do have > Factory in all such places. Nice high level idea Chia.. We can > clearly say things in each and every exposed class/interfaces. Will > make our life easy . > > -Anoop- > > On Fri, Dec 15, 2017 at 10:22 AM, Ted Yu <yuzhih...@gmail.com> wrote: > > We use @InterfaceStability.Stable in our codebase. > > > > If backward compatibility is kept, isn't the class / interface Stable ? > > > > Cheers > > > > On Thu, Dec 14, 2017 at 8:48 PM, Chia-Ping Tsai <chia7...@apache.org> > wrote: > > > >> hi folks, > >> > >> We have added many Public "read-only" interface in 2.0 to save user from > >> the dangerous operations. For example, TableDescriptor, > >> ColumnFamilyDescriptor, Region, Store, etc. However, this change make > us be > >> hard to enhance these interface (ie. add the new APIs) because the BC > will > >> be broken for the user having the subclass of these interfaces. In > contrast > >> with Cell, Filter, and coprocessor, these new interfaces are NOT > designed > >> to be a extendable class for user but we have no explicit caveat. As I > see > >> it, it is necessary to introduce an new annotation to explicitly say > "you > >> CAN extend this Public class with the BC guarantee". User should not > extend > >> the Public classes which don't have the such annotation. > >> > >> Any suggestions? > >> > >> Cheers > >> Chia-Ping > >> >
