accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] Hadoop3 support target?
Date Wed, 06 Dec 2017 19:17:36 GMT
On Wed, Dec 6, 2017 at 2:10 PM, Josh Elser <elserj@apache.org> wrote:
>
>
> On 12/6/17 2:06 PM, Christopher wrote:
>>
>> On Wed, Dec 6, 2017 at 1:55 PM Keith Turner <keith@deenlo.com> wrote:
>>
>>> On Wed, Dec 6, 2017 at 1:43 PM, Josh Elser <elserj@apache.org> wrote:
>>>>
>>>>
>>>>
>>>> On 12/6/17 12:17 PM, Keith Turner wrote:
>>>>>
>>>>>
>>>>> On Wed, Dec 6, 2017 at 11:56 AM, Josh Elser<elserj@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.

Mime
View raw message