accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [DISCUSS] Semantic Versioning
Date Wed, 03 Dec 2014 18:41:07 GMT
+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? 

----- 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