accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Semantic Versioning
Date Sat, 06 Dec 2014 21:07:41 GMT
On my first few readings, I felt it was a bit ambiguous, and wanted to make
it more clear. It may not be needed to add that language.


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message