accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <>
Subject Re: [DISCUSS] Semantic Versioning
Date Thu, 04 Dec 2014 12:53:03 GMT
One if the prerequisites that delayed us on adopting semver is that we
haven't defined what is covered when considering statement about

We'll need to come up with at least a first pass before we could vote. I'd
prefer it not just be the way we currently define the public API, since
that doesn't cover many practical concerns.

IIRC, one of the main reasons for waiting to 2.0 was to make explaining the
transition easier by allowing our versions to be roughly categorized as 1.x
and 2.x releases. Is anyone still concerned about this?

On Dec 3, 2014 12:30 PM, "Christopher" <> wrote:

> I don't want to issue another vote right now, but I just (re-read) the
> semantic versioning 2.0.0 document (, 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message