accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Beyond 1.6
Date Thu, 24 Apr 2014 15:45:43 GMT

I'd like to start the discussion about where we go after we release 
1.6.0. We have a lot of great ideas that people have outlined that 
together, I think, would make a really compelling version of Accumulo.

Besides a set of new features/changes, we've also talked about changing 
how we version the software in such a way that would better align with 
how we want to support it and the  guarantees we want to provide. Some 
of these will require additional discussion, but I believe there are a 
few things we could knock out ahead of time that will help in these 
later discussions (especially those regarding API, data and wire 

The easy one: is everyone happy with calling the next "major" version 
after 1.6.0, "2.0.0"? I believe that reclaiming that extra digit in our 
current version string (the "1" in 1.6.0) will help alleviate many of 
the problems that we've been facing in where code is "allowed" to go.

Going a little deeper, I think we can also agree to some *general* 
guidelines about what these numbers mean, following what semantic 
versioning generally outlines based on what we've been trying to follow 
to date. The major (most-significant) number refers to releases in which 
very impactful changes were made to the codebase. The minor (middle) 
number refers to changes/improvements which are lesser in nature, but do 
not represent a major shift in how to use or administer Accumulo. The 
bugix (least-significant) number should *only* contain the least 
impactful change which address some breakage in the code.

  - an important point that needs clarification is how we draw the line 
between which non-breaking changes can be put in a minor release and 
which must be introduced in a major release.

Bugfix versions should not make any compatibility changes at all - fix 
the bug as it stands. Minor versions can introduce additions to the 
public API, storage or wire implementations, but they should be done in 
a backwards compatible way. Major versions can remove deprecated public 
API calls. Data compatibility can be met with some upgrade process 
instead of full compatibility with the previous versions. Wire 
compatibility does not need to be guaranteed across major versions if 
this is not possible.

Then, we can target major releases ~yearly, minor releases every few 
months, and bugfix releases in order of weeks based on severity. I would 
also suggest that we reduce our testing burden for bugfixes to be more 
focused on verifying that the bugs have been identified in tests and 
verified as fixed.

This got a lot longer than I wanted, so I'm sorry for that. Please feel 
free to suggest pruning to this list so we can have a discussion that 
nets some actual results.

- Josh

View raw message