accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: [DISCUSS] Semantic Versioning
Date Fri, 05 Dec 2014 19:04:24 GMT
Let me try again, for clarity

[+1]: 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
[+1]: 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
[+1]: define scope of these versioning compatibility rules to  be our

* = Okay adopting this for the release following the release of the new API
** = This is dependent on the keep master branch named 1.7.0 so I'm afraid
to align myself to a vote against something in flux
*** = don't care (0) but it affects my other votes

On Fri, Dec 5, 2014 at 1:53 PM, Christopher <ctubbsii@apache.org> wrote:

> 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