I already cited sources for it in my previous response. On Wed, Dec 3, 2014 at 6:57 PM, Christopher <ctubb...@apache.org> wrote:
> On Wed, Dec 3, 2014 at 5:28 PM, John Vines <vi...@apache.org> wrote: > >> I stand by my -1. This vote would guarantee a level of API compatibility >> that I don't think we should be held to. >> >> > So, this degree of compatibility is our *current* practice between major > versions, and this is the default assumption I've been operating under. > These proposed guidelines do not presume to add that requirement... they > only assumes our current practice of API support between major releases > (something I feel we've consistently been getting better at since 1.5). > > Whether we should discard this current practice for 2.0 seems like a > separate conversation (though it may be a prerequisite for this vote), and > I'm not sure where the idea that developers would be on board with this > came from (a misunderstanding in a previous thread, perhaps?). Personally, > I would vote against discarding the current practice, because I think it's > a bad idea to introduce breaking changes without deprecating first, and > giving users some opportunity to migrate at their own pace when they > upgrade. > > This (mis?)understanding seems to be at the heart of a lot of the dialogue > on this list in the past few weeks. If you could direct me to some previous > thread which established consensus on the decision to discard the 1.x APIs > without deprecated support, I think it would help. > > >> 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 >>>>> > > > >>>>> > > >>>>> > >>>>> >>>> >>>> >>> >> >
