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:37:56 GMT
Sorry, bad copy/paste job there, should be " start operating under whatever rules we adopt
as of the master branch"

-----Original Message-----
From: dlmarion@comcast.net [mailto:dlmarion@comcast.net] 
Sent: Saturday, December 06, 2014 1:34 PM
To: dev@accumulo.apache.org
Subject: RE: [DISCUSS] Semantic Versioning

Christopher had asked for informal votes on, "releases [ +1]: start operating under whatever
rules we adopt as of the master branch," which to me means if we approve we adopt immediately.
IMO, putting off this decision is hurting us, see the other threads over the past week. I
don't believe that adopting semver now and applying it to 1.6.x and beyond hurts us in any
way.

-----Original Message-----
From: John Vines [mailto:vines@apache.org]
Sent: Saturday, December 06, 2014 1:19 PM
To: Accumulo Dev List
Subject: Re: [DISCUSS] Semantic Versioning

I think there's an issue with this course of discussion because we're discussion issues of
our current 1.x release style while also discussion Semver, both of which are incongruent
with one another. Perhaps we need to segregate adopting semver for 2.0.0 (which is waht I
assumed), vs. adopting semver for our next release vs. adopting semver for some release after
the next but before 2.0.0?

On Sat, Dec 6, 2014 at 1:16 PM, <dlmarion@comcast.net> wrote:

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