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 say 1.7 still, since it is consistent with our existing rules for determining a "major" release today, *and* it matches semver definition of a "minor" release, because it doesn't break backwards-compatibility compatibility from 1.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).
> ----- Original Message ----- > > From: "Christopher" <[email protected]> > To: "Accumulo Dev List" <[email protected]> > Sent: Wednesday, December 3, 2014 1:30:20 PM > Subject: [DISCUSS] Semantic Versioning > > I don't want to issue another vote right now, but I just (re-read) the > semantic versioning 2.0.0 document (http://semver.org/), and I think we > should just go ahead and adopt it and start abiding by it. > > In addition, I'd also like to ensure we provide some long-term stability > for deprecations. Semver only says we should have at least 1 minor release > with the deprecation documented. I think we should have at least one > (typically: exactly one) major release with the deprecation documented, > before breaking it in the next major release after that. > > Also, Semver also does not say anything about forward-compatibility, but I > think we do probably want to ensure forward compatibility between "patch" > releases (aka "bugfix" releases), in addition to backwards-compatibility. I > don't think it would make sense to add forward-compatibility to "minor" > releases, though, because that would prevent adding non-breaking features, > and that's the explicit purpose of Semver's "minor" releases. > > We've previously discussed versioning semantics, but never came to a > decision. I recall that there was some views that we should defer applying > these semantics until after 2.0 (that position was used to justify several > backports). However, given the stronger concerns more recently, regarding > API stability, it appears as though those views are different now, and > maybe we should just start applying this from 1.7 and forward. > > Semver with these two additions (forward-compatibility for patch releases, > and longer-deprecation cycle), basically encompasses the guidelines that I > suggested in the last [VOTE] thread about what to do between 1.7.0 and > 2.0.0, and also clarifies what I was thinking in terms of deprecations in > 2.0. If we adopt this, that thread is essentially moot. > > Thoughts? Are there any additions we'd like to see? Strong statements that > go beyond semver? Should we just vote on this? > > -- > Christopher L Tubbs II > http://gravatar.com/ctubbsii > >
