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 18:16:16 GMT
" This basically represents a goal to not to add new APIs without bumping the minor release."

 I didn't think that with semver you could change the API in a patch release. An API change,
if backwards compatible, requires a new MINOR release. Am I reading 6, 7, 8 and in the specification
incorrectly? I might need an example.

-----Original Message-----
From: Christopher [mailto:ctubbsii@apache.org] 
Sent: Saturday, December 06, 2014 12:53 PM
To: Accumulo Dev List
Subject: Re: [DISCUSS] Semantic Versioning

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


Mime
View raw message