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). >
The intention of 1.a was definitely to leave in the ClientConfiguration (deprecated) as-is until it is dropped entirely in 2.0. So, there'd be full source and binary compatibility while it exists, but it would go through a deprecation cycle and be dropped in 2.0, so users would have to switch to the replacement ClientConfig before 2.0.
