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.
