On Fri, Jun 26, 2015 at 12:43 PM, Mikhail Antonov <[email protected]> wrote:
> Thinking more on that.. What's the correlation between Public/Private > annotations and Deprecated annotation? I'm not sure SemVer has notion > of deprecation of non-public API. Should we say that we don't have it > too, or we do, but deprecation cycle of such API is more aggressive > than for public? > > There is none. If Private, semvar does not apply; no deprecation cycle necessary. What to do about Public/Evolving. semvar applies here? St.Ack > -Mikhail > > On Fri, Jun 26, 2015 at 12:31 PM, Mikhail Antonov <[email protected]> > wrote: > > In branch-1.0 HTable is {Private, Stable} with comment - > > > > * <p>HTable is no longer a client API. Use {@link Table} instead. It is > marked > > * InterfaceAudience.Private indicating that this is an HBase-internal > > class as defined in > > * <a href=" > https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/InterfaceClassification.html > ">Hadoop > > * Interface Classification</a> > > * There are no guarantees for backwards source / binary compatibility > > and methods or class can > > * change or go away without deprecation. > > > > So I think it's OK to remove such methods in 2.0. Otherwise, IMO, > > having to go thru full major version of deprecation kind of makes > > Private audience annotation meaningless? > > > > semver.org says: > > > > "Software using Semantic Versioning MUST declare a public API. This > > API could be declared in the code itself or exist strictly in > > documentation. However it is done, it should be precise and > > comprehensive. > > > > ..<skipped> > > > > Version 1.0.0 defines the public API. The way in which the version > > number is incremented after this release is dependent on this public > > API and how it changes." > > > > > > -Mikhail > > > > On Fri, Jun 26, 2015 at 11:20 AM, Sean Busbey <[email protected]> > wrote: > >> For a given major version, we should make sure to keep at least the > promise > >> we made when it started. > >> > >> For HBase 1.y, we said at 1.0 that we wouldn't remove public API without > >> having a full major version of deprecation. If only for that reason I > agree > >> wholeheartedly on the principle. > >> > >> But I thought HTable wasn't public API as of the 1.0 release. Is that > not > >> correct? > >> > >> -- > >> Sean > >> On Jun 26, 2015 12:59 PM, "Stack" <[email protected]> wrote: > >> > >>> (Intent is that this is a long-lived thread where we work out our > >>> transition to semantic versioning). > >>> > >>> In HBASE-13214 "Remove deprecated and unused methods from HTable > class", > >>> Ashish Singhi is doing nice cleanup work. His patch is removing > deprecated > >>> methods from HTable for hbase-2.0.0. A few methods up for removal are > >>> deprecated in hbase-1.1.0 but not in hbase-1.0.0. Ashish quotes > Semantic > >>> Versioning: > >>> > >>> "...issue a new minor release with the deprecation in place. Before you > >>> completely remove the functionality in a new major release there > should be > >>> at least one minor release that contains the deprecation so that users > can > >>> smoothly transition to the new API." > >>> > >>> So, Ashish's patch is well within what SV allows but to my mind we > need to > >>> be even more conservative if only during this period of transition to > SV. I > >>> think we should not remove deprecated methods, especially high-profile > >>> client-facing ones, until a major version has elapsed with the method > >>> deprecated. > >>> > >>> Opinions? > >>> Thanks, > >>> St.Ack > >>> > > > > > > > > -- > > Thanks, > > Michael Antonov > > > > -- > Thanks, > Michael Antonov >
