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