accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <dlmar...@comcast.net>
Subject RE: [DISCUSS] Semantic Versioning
Date Sat, 06 Dec 2014 14:55:04 GMT
[+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.
** if we vote to start operating under these rules, then the version should calculated when
development is done. 
*** where is the current definition documented?

-----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.
>


Mime
View raw message