On Tue, Dec 2, 2014 at 3:13 PM, Adam Fuchs <[email protected]> wrote:
> It seems to me like concensus instead of majority vote is preferable in the > case of exceptions. > > Maybe. it depends on the nature of the objection. if it's a routine release-planning thing, then majority might suffice. Consensus might be required if a change is objected/veto'd. I don't consider how to handle exceptions part of the above guidelines, upon which we are voting. I only wanted to express that I think that some exceptions might need further discussion beyond the guidelines. > Adam > On Dec 2, 2014 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). > > > > 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 > > > -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Dec 2, 2014 at 3:13 PM, Adam Fuchs <[email protected]> wrote: > 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" <[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). > > > > 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 > > >
