accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <>
Subject Re: [PROPOSAL] 1.7/2.0 branches and git workflow change
Date Tue, 07 Oct 2014 00:07:53 GMT
Can you step through what you expect the workflow to be when fixing e.g. a
bug against 1.5 using this model? Specifically after master is equivalent
to the 1.7.0 tag.

What purpose does the master branch serve if it's just the same as the last
major release tag?

On Oct 6, 2014 6:18 PM, "Christopher" <> wrote:

> Okay, so when we first switched to git, Josh argued that the master branch
> should be pristine... it should reflect the most recently released version.
> We have not been doing that. Instead, we've been treating it as the main
> development branch, following SVN conventions and treating it like trunk,
> constantly merging to it whenever we apply a fix/update to an earlier
> maintenance branch.
> I've been thinking about creating a 2.0 branch to work in to do stuff that
> we are planning to do for 2.0 that we have not yet committed to any branch
> (like drop deprecated code and drop support for Hadoop 1). I'm hesitant to
> do so if this branch will become yet another branch to merge through to
> master, especially if this ultimately isn't the branch that becomes 2.0.0
> release (for whatever reason).
> Constantly moving master significantly reduces our ability to decide which
> things to include in the next release (because they are essentially already
> included, unless we revert, which can complicate things).
> So, what I'd like to do is branch master as "1.7", and immediately stop
> commits to "master". This gives us time to all get used to the new
> workflow, while continuing to work towards 1.7.0.
> When 1.7.0 is released, I'd like to merge it onto "master" and leave it
> that way (pristine and identical to the 1.7.0 tag). This merge will be a
> fast-forward merge, because nobody should have been committing anything to
> master. If somebody makes a mistake and merges something to master, we have
> time to correct them before the 1.7.0 release, and if somebody makes a
> mistake after 1.7.0 is released and master is sync'd to it, we have other
> emergency recourse (reset / force push or, more likely, revert master /
> cherry-pick onto correct branch).
> There may be other benefits to this, but the main thing I'm interested in
> is greater control over what is included in a release, and long-term
> planning branches for planned future versions (like 2.0) that are not the
> immediate next release (like it appears 1.7.0 will be).
> Thoughts? Questions? Comments? Objections?
> --
> Christopher L Tubbs II

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