hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Semantic Versioning Worksheet
Date Sun, 28 Jun 2015 05:50:13 GMT
On Fri, Jun 26, 2015 at 12:31 PM, Mikhail Antonov <olorinbant@gmail.com>
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 <busbey@cloudera.com> 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" <stack@duboce.net> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message