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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> wrote: >> > >> > > Christopher wrote: >> > > >> > >> On Wed, Dec 3, 2014 at 1:41 PM,<[email protected]> 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 <[email protected]> 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 <[email protected]> >> wrote: >> > >> > > Christopher wrote: >> > > >> > >> On Wed, Dec 3, 2014 at 1:41 PM,<[email protected]> 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. >> > > >> > >> > >
