Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (nike.apache.org: domain of josh.elser@gmail.com designates
 209.85.216.169 as permitted sender)
Message-ID: <54E27414.3000800@gmail.com>
Date: Mon, 16 Feb 2015 17:49:56 -0500
From: Josh Elser <josh.elser@gmail.com>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: dev@accumulo.apache.org
Subject: Re: Current master branch version
References: 
 <CAGHyZ6+n0gyyerAKEP0XqFVKPZNTH-2HiZn0rnFbBPHXZAJYCw@mail.gmail.com>
 <CAPMpPc7AqoURMuxai_9jUGjZP7i66bMbA3qR9nW75y_L0i1Lig@mail.gmail.com>
 <CAL5zq9buWZe=QAmeXwjzrutzoOtwaoULD4=ks2yEVY84ehTseA@mail.gmail.com>
 <CAGHyZ6KMb8pr9PZaimADpjNjNu1XMcakjNLcs+=_rG-dmi=jJQ@mail.gmail.com>
In-Reply-To: 
 <CAGHyZ6KMb8pr9PZaimADpjNjNu1XMcakjNLcs+=_rG-dmi=jJQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Sean Busbey wrote:
> 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.
>

This sounds good to me too. It sucks that we screwed up with stuff that 
we considered to be "internal", but, unless there's something that 
fundamentally prevents us from reinstating the old stuff, I would think 
that's the best path. If it's not feasible to reinstate stuff, we should 
enumerate the specific instances and reasons why we can't/won't 
reinstate and then decide if we just want to apologize and ask for 
forgiveness from users.