accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dlmar...@comcast.net
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Wed, 03 Dec 2014 15:49:57 GMT

It also appears that what was predicted at the end of [1] has come true. Kudos to Christopher
for predicting the future. Have any lotto numbers in mind? 

[1] http://mail-archives.apache.org/mod_mbox/accumulo-dev/201404.mbox/%3CCAL5zq9aPieiDH%2BEkYLpjAu_RYRjAJ8n_ziH6jhzQvNE8XyNVAQ%40mail.gmail.com%3E

[2] http://mail-archives.apache.org/mod_mbox/accumulo-dev/201404.mbox/ajax/%3CCAL5zq9a8J6SXrUfsJsU9CB163%3D1QJgfurCKeLAj_GNTJW5hJuQ%40mail.gmail.com%3E



----- Original Message -----

From: dlmarion@comcast.net 
To: dev@accumulo.apache.org 
Sent: Wednesday, December 3, 2014 10:37:48 AM 
Subject: Re: [VOTE] API release policy for 1.7/2.0 


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


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


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



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message