On Tue, Nov 25, 2014 at 3:48 PM, Sean Busbey <bus...@cloudera.com> wrote:
> On Tue, Nov 25, 2014 at 2:39 PM, Christopher <ctubb...@apache.org> wrote: > > > On Tue, Nov 25, 2014 at 3:35 PM, Sean Busbey <bus...@cloudera.com> > wrote: > > > > > On Tue, Nov 25, 2014 at 2:16 PM, Keith Turner <ke...@deenlo.com> > wrote: > > > > > > > On Tue, Nov 25, 2014 at 2:57 PM, Sean Busbey <bus...@cloudera.com> > > > 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. > > > > > How about if we push this change in the API out to the client reworking in > 2.0? Everything will break there anyways so users will already have to deal > with the change. > > Once again, this change does not break anything. I understand wanting to reserve the deprecation of the old methods until 2.0, but I do not understand the objection for API additions/improvements in 1.7.0 that has no impact on existing methods or behavior. Also, since you can only veto changesets, and not release candidates, I don't see what would stop a release manager from backporting this changeset to 1.7 prior to its release if we push it to a 2.0 branch. I don't see why this improvement must be postponed.
