On Wed, Dec 3, 2014 at 10:46 AM, Sean Busbey <bus...@cloudera.com> wrote:
> On Wed, Dec 3, 2014 at 9:37 AM, <dlmar...@comcast.net> wrote: > > > > > > > ----- Original Message ----- > > > > From: "Keith Turner" <ke...@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 <ctubb...@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+...@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? > Yes > > -- > Sean >
