On Tue, Nov 25, 2014 at 3:35 PM, Sean Busbey <[email protected]> wrote:
> On Tue, Nov 25, 2014 at 2:16 PM, Keith Turner <[email protected]> wrote: > > > On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey <[email protected]> > wrote: > > > > > > altering the public API (as a standalone change) > > > > > > I am very conservative about changes to our public API. I have had to > > write > > > code that works across Accumulo versions and even when only working > with > > > the public API is it painful on almost every release. I have also seen > > > plenty of cases where deployments of Accumulo lag behind version > changes > > > because of this same issue. > > > > > > I fully support that major version changes are there for us to break > > APIs. > > > That doesn't mean that such breakage doesn't have a high cost that > needs > > to > > > be weighed carefully. > > > > > > In general, for me to be positive on an API change there needs to be a > > > compelling improvement or a correctness issue. For me, that correctness > > > > > > > Which API changes are you more concerned about? Deprecating two methods > > and/or the addition of a new method? > > > > > They're the same as far as I'm concerned. The intention is clearly to move > to the new method. The deprecation cycle will help when I need to have a > client that spans 1.6 and 1.7. It won't help when I need to span 1.6 to > whatever the version is where the deprecated stuff is removed. > > I'm perfectly content and willing to leave those methods un-deprecated, and provide longer API support for the older methods, if that's the main concern.
