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. -- Sean
