On Wed, Dec 3, 2014 at 4:41 PM, Christopher <[email protected]> wrote:
> On Wed, Dec 3, 2014 at 10:31 AM, Keith Turner <[email protected]> wrote: > > > On Tue, Dec 2, 2014 at 3:01 PM, Christopher <[email protected]> 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? > > > > > To clarify that last line, starting with "Existing API": when I say "should > only be subject to removal if it was already deprecated prior to 1.7.0", > what I mean to do is clarify which things are possible to consider for > removal: existing API will not be considered for removal; API deprecated > prior to that could be considered for removal. I do not intend to suggest > that these "must be" removed, or that they "should be" removed, or that > agreement with these guidelines is the same as agreement with any specific > removal. My only intention here was to define the scope of things which are > subject to the removal consideration process and which are not, to ensure > stability. > > The specific subset of "can be considered for removal" category is not > defined here, and is outside the scope of these guidelines. These > sounds good. I am ok w/ leaving that undefined and I like what the proposal does define, its a massive improvement over what we have. Changing vote to +1 Removal of eligible deprecated methods would be subject to CTR and that probably good enough for now. guidelines, as proposed, should be interpreted to be compatible with > removing all these things in this category, or preserving all of them, or > anywhere in between. The only thing I intend these guidelines to establish > is which things must not be removed, for the sake of backwards > compatibility/API stability guarantees. > > > > > > > > > > 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 > > > > > >
