accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [PROPOSAL] 1.7/2.0 branches and git workflow change
Date Tue, 07 Oct 2014 01:11:06 GMT
On Mon, Oct 6, 2014 at 8:07 PM, Sean Busbey <busbey@cloudera.com> wrote:

> 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.
>
>
The workflow is almost identical to before... just without the final merge
to master:

For a bug in 1.5, the patch is applied to the 1.5 branch, then merged to
1.6, then 1.7, but not to master. When 1.7.1 is released, master is updated
to 1.7.1.



> What purpose does the master branch serve if it's just the same as the last
> major release tag?
>
>
I think Josh had some specific opinions on this, but the general idea from
what I understood was that master is supposed to be stable...
representative of the latest, most modern release, because it's what a new
contributor would expect to fork to create a patch. That's hard to do if
the goalpost is moving a lot, and it makes feature merges more complicated,
since contributors have to rebase or merge themselves in order to create a
patch that merges cleanly. Having a stable master makes it very easy to
contribute to the most recent release.

But, this also gives us flexibility. If we automatically merge to master,
we're stuck with it and probably have to revert (which can get
complicated). However, if we're planning a 2.0 release, and we have
specific new features in 2.0, and it gets messed up in any way, we can
always cherry-pick or rebase what we want to keep onto a new 2.0 branch
from master, and merge any bugfixes that have occurred in the other
maintenance branches. The has good implications for release planning. It
also means we could avoid situations like constantly do a non-fastforward
merge because there was an early version name bump in the branch. We don't
have to be stuck with it.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii



> --
> Sean
> On Oct 6, 2014 6:18 PM, "Christopher" <ctubbsii@apache.org> 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
> > http://gravatar.com/ctubbsii
> >
>

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