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 > > [+1]: adopt semver 2.0.0 (http://semver.org) I have concerns that the following may be too strict. [+0]: 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 [+1]: start operating under whatever rules we adopt as of the master branch [+1]: keep the master branch named 1.7.0 [-1]: define scope of these versioning compatibility rules to be our current definition of "public API" and the wire version We have not offered guarantees of wire compatibility across minor releases before. This would be something new. I am not opposed to it on principal, but I think doing it properly would require a test suite that verifies the complete 1.(X-1) client API/jar works against a 1.X server. We have nothing like this, and I don't like the idea of saying we offer something w/ no way to validate. In the interest of making forward progress, I suggest the following. [+1]: define scope of these versioning compatibility rules to be our current definition of "public API" > 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. > > >
