Return-Path: X-Original-To: apmail-accumulo-dev-archive@www.apache.org Delivered-To: apmail-accumulo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 258681006C for ; Tue, 2 Dec 2014 20:13:38 +0000 (UTC) Received: (qmail 43953 invoked by uid 500); 2 Dec 2014 20:13:37 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 43913 invoked by uid 500); 2 Dec 2014 20:13:37 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 43902 invoked by uid 99); 2 Dec 2014 20:13:37 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Dec 2014 20:13:37 +0000 Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 2B19B1A0019 for ; Tue, 2 Dec 2014 20:13:16 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id hl2so16905653igb.0 for ; Tue, 02 Dec 2014 12:13:36 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.42.146.201 with SMTP id k9mr4343331icv.54.1417551216616; Tue, 02 Dec 2014 12:13:36 -0800 (PST) Received: by 10.107.136.143 with HTTP; Tue, 2 Dec 2014 12:13:36 -0800 (PST) Received: by 10.107.136.143 with HTTP; Tue, 2 Dec 2014 12:13:36 -0800 (PST) In-Reply-To: References: Date: Tue, 2 Dec 2014 15:13:36 -0500 Message-ID: Subject: Re: [VOTE] API release policy for 1.7/2.0 From: Adam Fuchs To: dev@accumulo.apache.org Content-Type: multipart/alternative; boundary=90e6ba613b66b7b0ed0509415cb9 --90e6ba613b66b7b0ed0509415cb9 Content-Type: text/plain; charset=UTF-8 It seems to me like concensus instead of majority vote is preferable in the case of exceptions. Adam On Dec 2, 2014 3:01 PM, "Christopher" 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). > > The purpose of these guidelines are to ensure the ability to add additional > functionality and evolve API naturally, while minimizing API disruptions to > the user base, in the interim before 2.0.0 when we can formally adopt an > API/versioning policy. > > Exceptions to these guidelines should be subject to a majority vote, on a > case-by-case basis. > > Because these relate to release planning, this vote will be subject to > majority vote, in accordance with our bylaws pertaining to release planning > and voting, and will be open for 3 days, concluding at 2000 on 5 Dec 2014 > UTC. > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > --90e6ba613b66b7b0ed0509415cb9--