accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Wed, 03 Dec 2014 15:31:11 GMT
On Wed, Dec 3, 2014 at 9:23 AM, John Vines <> wrote:

> Sent from my phone, please pardon the typos and brevity.
> On Dec 3, 2014 9:49 AM, "Sean Busbey" <> wrote:
> >
> > -1 also, ATM. I'd like to see us freeze APIs between now and the 2.0
> release.
> >
> > Downstream users have to plan when they invest effort in migrating
> Accumulo versions. We've already signaled that 2.0 will be the start of a
> new API with long-lived compatibility promises. (We should keep signaling
> this.) That makes it a promising place to make a jump (in some cases, from
> 1.4 I'm sure).
> >
> > I would like to avoid, however possible, leaning those users towards
> ignoring releases between now and 2.0. For those who are back on 1.4 or 1.5
> we can't really do too much. For those on 1.6 we can make it so there is
> relatively little risk in moving forward.
> >
> > API additions matter here because when a system integrator makes an
> application on top of Accumulo they often start at the latest version they
> can find. Later, they may have a client with a regulatory requirement to
> use an earlier version. Porting backwards is just as hard as porting
> forwards in our code base.
> >
> I have an issue with this line of reasoning. Not allowing new APIs for your
> reasoning sounds like a poor reason for not adding them. If we had no talk
> of doing a 2.0, making a request like that would be considered utterly
> unreasonable. And it's also a bit invalid given we already have other new
> APIs added.

I specifically only hold this position because of 2.0. Because we have 2.0
coming and we have internal changes we want to push out prior to that I
would like the differences from the client side to be minimal.

Also, it's not like API slips are all or none. The more changes we have the
more work it is for downstream users to consume and plan around those

> > I'd also like to see the "no removing of deprecated" language
> strengthened to remove the exception for things deprecated prior to 1.7.
> >
> > Yes, this will severely constrain what we can do prior to 2.0. But I
> think doing otherwise will just encourage us to keep squeezing in "just one
> more" major pre-2.0 release to get some additional client facing feature
> out the door.
> >
> If this is a concern then we should put effort into dictating a roadmap for
> features for 1.7 and 2.0. Enforcing this via API alteration limitations
> doesn't seem to be the right way to do this.

We already did that once and we will probably do it again. There can always
be something that comes up and restarts the discussion (and this is a good
thing). Constraining how those changes impact downstream clients at least
gives us room to have some subset of changes come in without having to
revisit the matter of if something should wait for 2.0.

> > If we have some downstream users with different compatibility needs and
> with particular operational needs for features that are delayed to 2.0
> because of this decision, it should be straight forward for them to
> backport the things they need and run their own packaging. Plenty of folks
> who don't need the legal indemnification that the ASF provides do this for
> a wide variety of projects.
> >
> Let's not go into a discussion about telling people to fork the code and do
> their own thing, shall we?
I was attempting to proactively address some concerns I saw previously
raised in another thread. You're correct it's probably too far afield for
this topic, my apologies.


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