Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
MIME-Version: 1.0
Sender: saint.ack@gmail.com
In-Reply-To: 
 <CAGHyZ6JeJykrjY1Lw521ZAEhZF2Zx98adgWEFk1ptUdJgCe08g@mail.gmail.com>
References: 
 <CADcMMgGwxoo_BUg4xwMQC=wYFVUn4s=a_ougW4q8pBRyUO4ErQ@mail.gmail.com>
	<CAGHyZ6JeJykrjY1Lw521ZAEhZF2Zx98adgWEFk1ptUdJgCe08g@mail.gmail.com>
Date: Fri, 26 Jun 2015 15:31:11 -0700
Message-ID: 
 <CADcMMgFCKgoEVN9NtiQAKj1AFu3+HusH6Jwg4hMqoRmjmUd_dw@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=001a113ed24c2b7c820519734c27

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

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?
>

That is correct. It is public stable in 0.98 and then private in 1.0. We
missed deprecating a few methods in 1.0.

Stack


>
> --
> 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
> >

--001a113ed24c2b7c820519734c27--