Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (athena.apache.org: domain of josh.elser@gmail.com
 designates 209.85.192.48 as permitted sender)
Message-ID: <548353B0.30606@gmail.com>
Date: Sat, 06 Dec 2014 14:06:24 -0500
From: Josh Elser <josh.elser@gmail.com>
User-Agent: Postbox 3.0.11 (Windows/20140602)
MIME-Version: 1.0
To: dev@accumulo.apache.org
Subject: Re: [DISCUSS] Semantic Versioning
References: 
 <CAL5zq9a_CV5N=oh8xaWC7Ar-uFJeW20ALf8q=fnKXMETdbxu8w@mail.gmail.com>
 <1481687993.13499212.1417632067373.JavaMail.zimbra@comcast.net>
 <CAL5zq9YMxGNFdN5uZpyuBNqja71wK8=Bv+BdXH15=mNcWjQGqw@mail.gmail.com>
 <5480B15C.1010308@gmail.com>
 <CAL5zq9bbxRjPTfTJsTZfJjMMunTwKNHYno_M+2DqaNqdfgp1Qg@mail.gmail.com>
In-Reply-To: 
 <CAL5zq9bbxRjPTfTJsTZfJjMMunTwKNHYno_M+2DqaNqdfgp1Qg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

[+1]: adopt semver 2.0.0 (http://semver.org)
[+1]: adopt additional strictness to require documenting deprecation for at
least 1 major release before possible to consider in the next major release
[+1]: adopt additional strictness to ensure forward compatibility between
bugfix releases
[-0]: start operating under whatever rules we adopt as of the master branch
[-0]: keep the master branch named 1.7.0
[-0]: define scope of these versioning compatibility rules to  be our
current definition of "public API" and the wire version

As I said down below, I don't think trying to fully adopt semver when 
we're still on 1.X is going to work out well because we're missing the 3 
necessary version components. I think we should continue to operate as 
we had and just address whatever concerns devs have until 2.0.0.

Also, as Keith very well stated already, wire compat is a new guarantee 
and, if we do decide to make such a guarantee, we should have some 
mechanism in place for the first such release we make with the 
guarantee. A quick solution here is to have a champion behind the 
wire-compat testing who can shepherd it into the targeted release.

Christopher wrote:
> It would be helpful to this thread, if we can get some informal votes on
> the following propositions:
>
> [ ]: adopt semver 2.0.0 (http://semver.org)
> [ ]: adopt additional strictness to require documenting deprecation for at
> least 1 major release before possible to consider in the next major release
> [ ]: adopt additional strictness to ensure forward compatibility between
> bugfix releases
> [ ]: start operating under whatever rules we adopt as of the master branch
> [ ]: keep the master branch named 1.7.0
> [ ]: define scope of these versioning compatibility rules to  be our
> current definition of "public API" and the wire version
>
> I'm going to assume it's a given that if any exceptional situations arise,
> we'll handle those through further discussions/voting, as appropriate.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser<josh.elser@gmail.com>  wrote:
>
>> Christopher wrote:
>>
>>> On Wed, Dec 3, 2014 at 1:41 PM,<dlmarion@comcast.net>   wrote:
>>>
>>>   >   +1 to semver
>>>>>   +1 to 1 major release before removing deprecated items
>>>>>   +1 to forward compatibility between bugfix releases
>>>>>
>>>>>   What's the version # for the master branch if these rules are applied?
>>>>>
>>>>>
>>> Well, I'd say1.7  still, since it is consistent with our existing rules
>>> for
>>> determining a "major" releasetoday,  *and*  it matches semver definition
>>> of
>>> a "minor" release, because it doesn't break backwards-compatibility
>>> compatibility from1.6  (with one tiny exception of dropping
>>> Instance.getConfiguration()... because it was an exceptional situation
>>> discussed in previous threads; if people are uncomfortable with that
>>> exception, I can return it to the API, if it helps achieve consensus
>>> here).
>>>
>>>
>> Sounds right to me.
>>
>> When we actually have code to land in Apache for 2.0.0, I figured we'd
>> break 1.7.X off to branch named "1.7" and master would become 2.0.0. We can
>> have some feature branch in Apache off to the side to make sure 2.0.0
>> development can happen in a shared environment before making the above
>> switch.
>>
>