On Feb 16, 2015 2:17 PM, "Christopher" <[email protected]> wrote: > > 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. >
Since the mapreduce.lib.util classes have been published as public api under semver (at a minimum in 1.6.2), we should maintain them if we don't want to make a major version bump. > 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. > > +1 Unless someone else beats me to it, I'll wait a couple days to see if there's any more discussion and then file a blocker on 1.7.0 with the current gaps. -- Sean On Feb 16, 2015 2:17 PM, "Christopher" <[email protected]> wrote: > 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 > > > > > >
