Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: <01d501d01164$9ed1dd60$dc759820$@comcast.net>
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>
	<01d501d01164$9ed1dd60$dc759820$@comcast.net>
Date: Sat, 6 Dec 2014 12:53:20 -0500
Message-ID: 
 <CAL5zq9YQANNJ4GgwW90saN2ZA_Pfc+QZYxxzRzza4=DzxDWXmQ@mail.gmail.com>
Subject: Re: [DISCUSS] Semantic Versioning
From: Christopher <ctubbsii@apache.org>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=047d7b34419c763c6805098fde58

--047d7b34419c763c6805098fde58
Content-Type: text/plain; charset=UTF-8

On Sat, Dec 6, 2014 at 9:55 AM, <dlmarion@comcast.net> wrote:

> [+1 ]: adopt semver 2.0.0 (http://semver.org)
> [0 ]: 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
> [ +1]: start operating under whatever rules we adopt as of the master
> branch
> [** ]: keep the master branch named 1.7.0
> [ +1***]: define scope of these versioning compatibility rules to  be our
> current definition of "public API" and the wire version
>
> * I'm confused by this. A change in 1.6.1 is forward compatible until it's
> not. If a patch is applied to 1.6.2 that is not backwards compatible, then
> that version is not 1.6.2, it's 1.7.0.
>

This basically represents a goal to not to add new APIs without bumping the
minor release. That way, code written against 1.6.2 would run against a
1.6.1 instance.


> ** if we vote to start operating under these rules, then the version
> should calculated when development is done.
>

It can be, yes... but we can also ensure we don't have any removals that
would force the calculation to bump higher than we want it to be. Keeping
the master branch 1.7 means that we fix the calculation.


> *** where is the current definition documented?
>
>
The README


> -----Original Message-----
> From: Christopher [mailto:ctubbsii@apache.org]
> Sent: Friday, December 05, 2014 1:46 PM
> To: Accumulo Dev List
> Subject: Re: [DISCUSS] Semantic Versioning
>
> 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.
> >
>
>

--047d7b34419c763c6805098fde58--