Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (nike.apache.org: domain of busbey@cloudera.com designates
 209.85.216.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1096155329.13214320.1417621068018.JavaMail.zimbra@comcast.net>
References: 
 <CAL5zq9Y3Owj7dUd_ZZyhdGGZ7FQ+79ufgcLORJjjzUmMckBrsA@mail.gmail.com>
 <CAGUtCHoG_aYpNG14FhCnar_-yuuTkf4xpWdzx8px3gn1UyF7Gg@mail.gmail.com>
 <1096155329.13214320.1417621068018.JavaMail.zimbra@comcast.net>
From: Sean Busbey <busbey@cloudera.com>
Date: Wed, 3 Dec 2014 09:46:01 -0600
Message-ID: 
 <CAGHyZ6+cTcaifgam0U4JyMxD_3NTDcxh=h9fqZmkCF3k_Pmaxw@mail.gmail.com>
Subject: Re: [VOTE] API release policy for 1.7/2.0
To: "dev@accumulo apache. org" <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=001a11338022cbcb29050951be84

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

On Wed, Dec 3, 2014 at 9:37 AM, <dlmarion@comcast.net> wrote:

>
>
> ----- Original Message -----
>
> From: "Keith Turner" <keith@deenlo.com>
> To: "Accumulo Dev List" <dev@accumulo.apache.org>
> Sent: Wednesday, December 3, 2014 10:31:53 AM
> Subject: Re: [VOTE] API release policy for 1.7/2.0
>
> On Tue, Dec 2, 2014 at 3:01 PM, Christopher <ctubbsii@apache.org> wrote:
>
> > Following the conversation on the [VOTE] thread for ACCUMULO-3176, it
> seems
> > we require an explicit API guidelines at least for 1.7.0 and later until
> > 2.0.0.
> >
> > I hereby propose we adopt the following guidelines for future releases
> (if
> > we produce any such releases) until 2.0.0:
> >
> > API additions are permitted in "major" 1.x releases (1.7, 1.8, 1.9, 1.10,
> > etc.).
> > API should be forwards and backwards compatible within a 1.x release (no
> > new additions to the API in a "bugfix" release; e.g. 1.7.1).
> > New API in 1.7.0 and later 1.x releases will not be removed in 2.0
> (though
> > they may be deprecated in 2.0 and subject to removal in 3.0).
> > Existing API in 1.7.0 will be preserved through 2.0, and should only be
> > subject to removal if it was already deprecated prior to 1.7.0 (though
> they
> > may be deprecated in 2.0 and subject to removal in 3.0).
> >
>
> -1 For the reason I stated earlier. I think we are setting ourselves to
> waste time in the future debating this by not making a more firm decision
> now about which deprecated methods will be dropped. In the earlier email I
> listed two options, are there other options?
>


> It seems that we already had this discussion[1] and a conclusion[2]. No
> vote though.
>
> [1]
> http://mail-archives.apache.org/mod_mbox/accumulo-dev/201410.mbox/%3CCAL5zq9ah+G+oMqR_p5E09Cwyue0K2ztVoJ10h+GriKOvhe+ggQ@mail.gmail.com%3E
> [2]
> http://mail-archives.apache.org/mod_mbox/accumulo-dev/201410.mbox/%3CCAL5zq9aaiCCO%2B%2BtwkKzNzw_xpjTQtPj%3DV%3DrEFUDR-eKoSAHBuQ%40mail.gmail.com%3E
>
>
That discussion did a good job of coming to consensus on not remove any
deprecated methods earlier than 2.0.

I believe Keith's concern is that he'd like to specify what is and is not
getting dropped at 2.0. The original proposal only says that things added
in 1.7+ won't be dropped earlier than 3.0. It leaves the fate of things
deprecated prior to 1.7 ambiguous in the 2.0 release.

Did I correctly restate your concern Keith?

-- 
Sean

--001a11338022cbcb29050951be84--