In favor of stability, I think we should re-add anything that was removed prematurely, where it makes sense to do so. Some things, like the mapreduce.lib.util classes I believe were removed due to the fact that it inadvertently fell into the definition of public API when it never should have been, and were moved shortly after clarifying what precisely was included in "public API" (I believe they were added prior to that definition being added, if I'm remembering correctly). I'm not sure it makes sense to reintroduce those... because they were never expected to be used by users anyway (and therefore were moved prior to adopting semver), but if we really want to be strict about that, we can do those, too.
In general, I think we now want to avoid taking away methods, which means no bumping major version, unless/until there's compelling API changes that would warrant such a move. So, I'm in favor of keeping it at whatever it takes to be 1.7.0 for now. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, Feb 16, 2015 at 1:51 PM, Adam Fuchs <[email protected]> wrote: > I don't think bumping up to 2.0 lets us break compatibility anyway (without > a deprecation cycle), so I think option B is the only option if we're going > to release another version. > > Adam > > > On Feb 16, 2015 4:00 AM, "Sean Busbey" <[email protected]> wrote: > > > Hi folks. > > > > I just ran an updated compatibility check between the newly approved > 1.6.2 > > and master: > > > > > > > http://people.apache.org/~busbey/compat_reports/accumulo/1.6.2_to_1.7.0-SNAPSHOT/compat_report.html > > > > A number of incompatibilities are present. Would folks prefer to > increment > > to 2.0.0-SNAPSHOT or does someone want to work through reinstating > things? > > > > -- > > Sean > > >
