accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: Current master branch version
Date Mon, 16 Feb 2015 21:34:01 GMT
On Feb 16, 2015 2:17 PM, "Christopher" <ctubbsii@apache.org> 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" <ctubbsii@apache.org> 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 <afuchs@apache.org> 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" <busbey@cloudera.com> 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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message