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 Fri, 05 Dec 2014 19:18:58 GMT
I'm inclined to agree with you on the wire version. I guess it's something
I proposed without thinking it through. If the API is backwards compatible,
then the user just needs to use the newer jars to be able to function
without changing their application code.

I think we would need forward compatibility within bugfix versions, though,
for the wire version, in order to support rolling upgrades, which is what
we're doing now with the wire version. If we want to support rolling
upgrades beyond that, I guess we'll have to discuss wire version
compatibility separately in that context.


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

On Fri, Dec 5, 2014 at 2:11 PM, Keith Turner <keith@deenlo.com> wrote:

> 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