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
