accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject [PROPOSAL] 1.7/2.0 branches and git workflow change
Date Mon, 06 Oct 2014 23:18:34 GMT
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
http://gravatar.com/ctubbsii

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