accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: [DISCUSS] Semantic Versioning
Date Thu, 04 Dec 2014 18:57:55 GMT
On Wed, Dec 3, 2014 at 1:41 PM, <> 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" <>
> To: "Accumulo Dev List" <>
> 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 (, 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