On Wed, Dec 6, 2017 at 2:10 PM, Josh Elser <els...@apache.org> wrote: > > > On 12/6/17 2:06 PM, Christopher wrote: >> >> On Wed, Dec 6, 2017 at 1:55 PM Keith Turner <ke...@deenlo.com> wrote: >> >>> On Wed, Dec 6, 2017 at 1:43 PM, Josh Elser <els...@apache.org> wrote: >>>> >>>> >>>> >>>> On 12/6/17 12:17 PM, Keith Turner wrote: >>>>> >>>>> >>>>> On Wed, Dec 6, 2017 at 11:56 AM, Josh Elser<els...@apache.org> wrote: >>>>>> >>>>>> >>>>>> Maybe a difference in interpretation: >>>>>> >>>>>> I was seeing 1a as being source-compatible still. My assumption was >>> >>> that >>>>>> >>>>>> "Deprecate ClientConfiguration" meant that it would remain in the >>>>>> codebase >>>>>> -- "replace" as in "replace expected user invocation", not removal of >>> >>> the >>>>>> >>>>>> old ClientConfiguration and addition of a new ClientConfig class. >>>>> >>>>> >>>>> Ok, if we deprecate ClientConfiguration, leave it in 2.0, and drop the >>>>> extends from ClientConfiguration in 2.0. Then I am not sure what the >>>>> benefit of introducing the new ClientConfig type is? >>>> >>>> >>>> >>>> I read this as leaving the extends in ClientConfiguration and dropping >>> >>> that >>>> >>>> in the new ClientConfig. Agree, I wouldn't see the point in changing the >>>> parent class of ClientConfiguration (as that would break things). >>> >>> >>> >>> I don't think we can leave ClientConfiguration as deprecated and >>> extending commons config in Accumulo 2.0. This leaves commons config >>> 1 in the API. >>> >>> Personally I am not in favor of dropping ClientConfiguration in 2.0, >>> which is why I was in favor option b. >>> >> >> In the absence of any further input from others, I'll follow along with >> whatever you and Josh can agree on. Although I lean towards option 1.a, I >> don't feel strongly about either option. We can also do a vote if neither >> of you is able (or willing) to convince the other of your preference. > > > I don't feel strongly enough either way to raise a stink. Color me surprised > that Keith is the one to encourage quick removals from API :)
I think there is a misunderstanding lurking in all of these words :) Both options that Christopher proposed involve removing stuff from API. I am advocating for an option that removes less stuff from API. Below is what I'm advocating for. * Deprecate ZooKeeperInstance constuctor that takes commons config type in 1.9 * Add ZooKeeperInstance constructor that takes ClientConfiguration type in 1.9 * Drop ZooKeeperInstance constuctor that takes commons config type in 2.0 * Drop extends commons config type from ClientConfiguration in 2.0. Josh, can you please share what actions you are advocating for? I think we are misunderstanding each other. > > If he's OK with it, I'm fine with it. I was trying to err on the side of > less breakage.
