accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Semantic Versioning
Date Thu, 04 Dec 2014 18:51:09 GMT
On Thu, Dec 4, 2014 at 7:53 AM, Sean Busbey <busbey@cloudera.com> wrote:

> One if the prerequisites that delayed us on adopting semver is that we
> haven't defined what is covered when considering statement about
> compatibility.
>
>
True. We can use our current definition of "public API", and our "wire
version" and "data version" (now that we have one).
Granted, the definition of our "public API" would be larger for a short
transition period (adds the client jar in 2.0), until deprecated code goes
away. Despite the slight complexity of the current definition of "public
API", I think the benefits of actually having a reliable statement of
intent regarding compatibility guarantees significantly outweighs any
negative consequences of having that complicated definition. And, in any
case, that definition is complicated today, and we've been doing something
like semver with that complicated definition already.


> 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?
>
>
Honestly, I probably was concerned about this in the past. But, right now,
I think it's more important that we establish strong versioning semantics
so we can offer API compatibility guarantees to users who already use our
current API and pretty much understand what we mean when we say "public
API".


> --
> Sean
> On Dec 3, 2014 12:30 PM, "Christopher" <ctubbsii@apache.org> wrote:
>
> > 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
> >
>

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