Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of saint.ack@gmail.com designates
 209.85.213.172 as permitted sender)
MIME-Version: 1.0
Sender: saint.ack@gmail.com
In-Reply-To: 
 <CAHxLZBUodHMdGpi3dOE4ZffgfDTfbWGjrXLk74dP9L1GeCb8gw@mail.gmail.com>
References: 
 <CADcMMgGwxoo_BUg4xwMQC=wYFVUn4s=a_ougW4q8pBRyUO4ErQ@mail.gmail.com>
	<CAGHyZ6JeJykrjY1Lw521ZAEhZF2Zx98adgWEFk1ptUdJgCe08g@mail.gmail.com>
	<CAHxLZBW6nneL=gfWtpe88_r33JXBp6fV=9f3eF9pQ0PXLUr+AA@mail.gmail.com>
	<CAHxLZBUodHMdGpi3dOE4ZffgfDTfbWGjrXLk74dP9L1GeCb8gw@mail.gmail.com>
Date: Sat, 27 Jun 2015 22:56:30 -0700
Message-ID: 
 <CADcMMgHbJPdTLcksR0Z5xLM-uxyfb65KWh5ERapYnBGxvssWnA@mail.gmail.com>
Subject: Re: Semantic Versioning Worksheet
From: Stack <stack@duboce.net>
To: HBase Dev List <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2f82c81c6dd05198da228

--001a11c2f82c81c6dd05198da228
Content-Type: text/plain; charset=UTF-8

On Fri, Jun 26, 2015 at 12:43 PM, Mikhail Antonov <olorinbant@gmail.com>
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 <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. 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 <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
>
>
>
> --
> Thanks,
> Michael Antonov
>

--001a11c2f82c81c6dd05198da228--