-1 I do not like the idea of committing to 1.7.0-1.9.9... API additions for the 2.0 API. We have already come to the consensus that 2.0 will break the 1.x API which provides a lot of breathing room and freedom from old decisions. This causes this issue to come roaring back and an even larger amount of scrutiny to be required for all 1.7.0-1.9.9... API changes. I would go so far as to say an undefinable amount of scrutiny since we still don't have solid foundation of a 2.0 API. We cannot judge API items for how well they belong in an API that does not exist yet.
Tangential- I would like to see a clause about all current API items will not be removed (still could be deprecated) until 2.0.0, as I feel this may ease some concerns about API alteration in 1.7+. 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). > > 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 >
