accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes
Date Mon, 12 May 2014 17:38:30 GMT
Presumably, it would be based on the tag being fixed, and may include
commits from the next minor release. I'm not sure exactly how that
workflow would go. There may be other workflows, but I was thinking
something like:

1. Create a bugfix release plan
2. Branch the latest tag being bugfix'ed
3. Apply commits to fix bugs
4. Test fixes
5. Release bugfix
6. Merge to next minor/major releases in development once released

Christopher L Tubbs II

On Mon, May 12, 2014 at 10:08 AM, Alex Moundalexis
<> wrote:
> Makes sense to me.
> To confirm, a bug fix release will just cut from whatever specific commit
> is selected by the proposer?
> On Sun, May 11, 2014 at 3: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

View raw message