I'm inclined to agree with you on the wire version. I guess it's something I proposed without thinking it through. If the API is backwards compatible, then the user just needs to use the newer jars to be able to function without changing their application code.
I think we would need forward compatibility within bugfix versions, though, for the wire version, in order to support rolling upgrades, which is what we're doing now with the wire version. If we want to support rolling upgrades beyond that, I guess we'll have to discuss wire version compatibility separately in that context. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Fri, Dec 5, 2014 at 2:11 PM, Keith Turner <[email protected]> wrote: > 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. > > > > > >
