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:19:37 GMT
On Mon, Oct 6, 2014 at 8:38 PM, William Slacum <
wilhelm.von.cloud@accumulo.net> wrote:

> 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.
>
>
Yes, but that merge to master will always be a FF merge, and it will leave
the master branch stable for contributors to create topic branches from
without moving their goalposts. And the more explicit name is a benefit,
I'd argue.



> 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.
>
>
Why not? If we're working towards faster bugfix releases, this model still
works well.


> 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.
>

Well, no... that's what I'm proposing. If we create a 2.0 branch now, the
current workflow says merge to 2.0, then to master... that's what I'm
trying to avoid. But... we've got to leave master in *some* good state, and
this proposal gives us a reasonable state to stick to (for benefits named
above). What I'm trying to suggest is that we make "the time ... that we
want its history to be accounted for in the master branch" an action that
represents precisely such an explicit conscious decision. Right now, the
workflow says it's the next version so merge it, because we have no good
way of determining which version will be the next release.

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




>
> 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