All,
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
compatitbility).
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
