>>> The change of HTable from public/stable to private/stable is abrupt without >>> a transition through deprecation.
I actually missed this part, looked at branch-1.0 but no further behind. Then we may want to keep it longer.. I'm fine either way. >>> There is none. If Private, semvar does not apply; no deprecation cycle >>> necessary. Given that case with abrupt transition of HTable, wondering if we want to restrict transitioning from public to private, so it's not used as a loophole :) >>> What to do about Public/Evolving. semvar applies here? When we introduce new client facing features, do we first mark them public/evolving, and then promote to public/stable after every detail settles down and get polished? Thinking out loud, I'd say - public/evolving would comply with semver, except maybe that adding new backward-compatible functionality in patch release is ok too. This may allow us to faster absorb users' feedback on experimental things? -Mikhail On Sat, Jun 27, 2015 at 10:50 PM, Stack <[email protected]> wrote: > 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. > > > That is pretty clear. I'm sure no one reads it but it is very explicit. > > > >> Otherwise, IMO, >> having to go thru full major version of deprecation kind of makes >> Private audience annotation meaningless? >> >> > As you are point out later, they are not connected. The change of HTable > from public/stable to private/stable is abrupt without a transition through > deprecation. > > > >> 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." >> >> > > We are talking about a couple of methods; the getStartKeys and getEndKeys > that are in HTable (The methods are moved to RegionLocator). > > Between the class comment and the semvar quote, IMO, it is coverage enough > for our removing these few methods in 2.0. > > Speak up if you disagree. > > Thanks, > St.Ack > > > > > > > > > > > > >> >> -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
