I stand by my -1. This vote would guarantee a level of API compatibility that I don't think we should be held to.
On Wed, Dec 3, 2014 at 5:15 PM, Christopher <ctubb...@apache.org> wrote: > Does this information affect your vote? > > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > > On Tue, Dec 2, 2014 at 6:16 PM, Christopher <ctubb...@apache.org> wrote: > >> On Tue, Dec 2, 2014 at 5:18 PM, John Vines <vi...@apache.org> wrote: >> >>> 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. >>> >>> >>> >> We're not just going to drop the 1.x API. The core jar will still exist, >> and contain all the old APIs (at least, that was my understanding). We >> weren't going to throw out the window our normal practice of deprecating >> APIs (I certainly had no intentions to do so). My understanding would be >> that we would deprecate the old 1.x APIs in 2.0, and remove them in 3.0. >> >> I've not even considered this as a "new requirement" for the new client >> API... it's just the way we do things in this community (deprecate first, >> remove later). The only difference would be that the version numbers would >> actually mean something in terms of guarantees about when we remove those >> deprecated methods. This is what I've consistently expressed in the >> previous thread regarding ACCUMULO-3176. >> >> >> >>> > >>> > >>> > > 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 >>> > > > >>> > > >>> > >>> >> >> >
