accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Slacum <wilhelm.von.cl...@accumulo.net>
Subject Re: [PROPOSAL] 1.7/2.0 branches and git workflow change
Date Tue, 07 Oct 2014 00:38:16 GMT
I'm confused. Merging through a branch that's not master to avoid merging
through master doesn't really make anything less complicated. We still have
to merge through to master any ways to have it be the latest stable
release. All we have is another branch that has a more specific name.

Most of the theory behind what Josh wanted comes from this blog post:
http://nvie.com/posts/a-successful-git-branching-model/ One of the
disconnects between our branching strategy and the one it describes is that
it doesn't really account for long term support branches. I don't think
it's a good fit if we plan on supporting more than one release line.

There's no harm in branching a 2.0 branch that may or may not be merged in
to master, or have other commits forwarded. Its existence has nothing to do
with master until the time comes that we want its history to be accounted
for in the master branch.

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.
>
> What purpose does the master branch serve if it's just the same as the last
> major release tag?
>
> --
> 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