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