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
