On Tue, Dec 2, 2014 at 3:14 PM, Christopher <ctubb...@apache.org> wrote:
> On Tue, Dec 2, 2014 at 3:07 PM, John Vines <vi...@apache.org> wrote: > > > -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. > > > > > Honestly, I don't expect us to have any major 1.x releases after 1.7.x. > These guidelines would just add some minor protection, making 1.x a bit > more stable in the transition to 2.0 if we ever do have such releases. I'd > hate for a user to seamlessly migrate to 2.0 from 1.7, but not be able to > seamlessly migrate from a 1.8 to 2.0, because 1.8 dropped some 1.7 API. > This doesn't make any sense. I've been under the impression that there will not be a seamless migration to 2.0 from any release. I thought 2.0 was supposed to be a clean start of an API in order to prevent old method signatures from making a better, cleaner API. And with that, it means that migrating from 1.7 shouldn't make any different from 1.8. I expect there to be no necessity for any api in any version of 1.x to exist in 2.0, including those introduced in 1.999.0 if that's what it takes. Your statement specifies differently and that either means my bases for 2.0's API is false or your now introducing a new requirement to it. > > > > 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+. > > > > > I believe I expressed that above, and only excluded things that were > deprecated prior to 1.7 (such as aggregators, which I expect to drop in > 2.0). > > > > 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 > > > > > >
