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