accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <>
Subject Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes
Date Mon, 12 May 2014 14:41:25 GMT
On Sun, May 11, 2014 at 6:54 PM, Josh Elser <> wrote:

> SGTM. Looks like there aren't currently any fixes of much substance for
> 1.6.1 presently, but there are a few that would make for a very-low impact
> 1.6.1, and a good 1.5.2 which also includes the fallout tickets shortly
> after 1.5.1. Timeframe looks good to me too.
> If we can get that reduced test burden for "real" bug-fix releases
> hammered out, a month sounds good to me.

Rather than reduce the test burden, it would be nice to make the cluster
testing more automated like you and other have discussed.

> On 5/11/2014 6:15 PM, Christopher wrote:
>> Accumulo developers:
>> As part of our transition to better versioning standards, and more
>> regular releases, with better release planning, I was thinking that
>> our development branches should generally reflect an anticipated
>> minor/major release version, and not an expected bugfix version. It
>> seems to me that we should focus active development on minor/major
>> releases, and branch for bugfix releases temporarily, only to push out
>> an important bugfix.
>> With that in mind, I'd like to change the current 1.6.1-SNAPSHOT to
>> 1.7.0-SNAPSHOT in expectation for a forthcoming minor release (we
>> would have to discuss what kinds of things we'd want in such a
>> release. Minimally, I want ACCUMULO-1691), and the master branch to
>> 2.0.0 for development on the next major release.
>> If there's any outstanding bugfixes in the 1.6.1-SNAPSHOT branch that
>> would warrant a separate bugfix release, I think we should discuss
>> them and plan for a 1.6.1 within a month or so (along with a 1.5.2).
>> I'd like to discuss this here a bit and see if this makes sense before
>> initiating a vote on it.
>> --
>> Christopher L Tubbs II

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