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 18:53:56 GMT
Does X mean "+1" here? And, are the ones you omitted undecided, or "-1".


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

On Fri, Dec 5, 2014 at 1:51 PM, John Vines <vines@apache.org> wrote:

> [X]: 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
> [X]: 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
> [X]: define scope of these versioning compatibility rules to  be our
> current definition of "public API" and the wire version
>
>
> 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
> >
> > 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.
> > >
> >
>
>
> 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
> >
> > 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