accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] Semantic Versioning
Date Fri, 05 Dec 2014 19:11:46 GMT
On Fri, Dec 5, 2014 at 1:46 PM, Christopher <ctubbsii@apache.org> wrote:

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

[+1]: adopt semver 2.0.0 (http://semver.org)

I have concerns that the following may be too strict.

[+0]: adopt additional strictness to require documenting deprecation for at
least 1 major release before possible to consider in the next major release
[+1]: adopt additional strictness to ensure forward compatibility between
bugfix releases
[+1]: start operating under whatever rules we adopt as of the master branch
[+1]: 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

We have not offered guarantees of wire compatibility across minor releases
before.   This would be something new.  I am not opposed to it on
principal, but I think doing it properly would require a test suite that
verifies the complete 1.(X-1) client API/jar works against a 1.X server.
We have nothing like this, and I don't like the idea of saying we offer
something w/ no way to validate.  In the interest of making forward
progress, I suggest the following.
[+1]: define scope of these versioning compatibility rules to  be our
current definition of "public API"




> 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