incubator-crunch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Friedrich <>
Subject Re: Release preparations: Branching model
Date Fri, 10 Aug 2012 14:35:54 GMT

I had a quick look at gitflow when I was first looking for best 
practices with git. The need for a (complex) diagram and the fact
that there's a tool to support the process is a clear warning sign :)

The upside of gitflow is that there's a nice web page you can link to.
The downside is that it's obviously geared towards website development
where you only have to maintain one version of your software. As soon
as you need to maintain more than one release line you'd have to work
outside the model. This shortcoming makes gitflow unsuitable for
product development (and Crunch is a product).

The classic model uses a main line where development and integration
of feature branches happen. Unlike in gitflow, release branches are
long-running and stay alive as long as you support the release line
(ie. 0.3.x). If at all possible, merges happen from release branches
into the main line, so there is just one merge direction which
simplifies things.

In gitflow, even the standard bugfix case ("hotfix") requires merging
in multiple directions. From my experience, more complex merging
patterns lead to regressions sooner or later when people forget
merges, especially when in a hurry (test cases can't help you and we
don't have a QA team to catch them). In our case it's also difficult
to gather around a whiteboard when things go wrong, so simplicity
should be key.

Unless I really got it wrong, I think in gitflow they managed to
design a system that's both more complex and less capable than the
classic approach ;-)

Looking from a prospective contributor's perspective, we have two use
cases to consider:

  1. Contribute a new feature (=> check out master)
  2. Fix a bug in, say, 0.3.0 (=> check out branch "release-0.3.x")

Easy to explain, git novices know it from CVS or Subversion. No need
to learn a new process on top of a new revision control system.


P.S.: If you really want to dig into this, see "Streamed Lines"
by Appleton et al, for example. Careful though, this topic is among
the dullest in all software engineering.

On Thursday, 2012-08-09, Josh Wills wrote:
> The only other serious contender to a release management process would be
> git flow, i.e.,
> If I was to summarize the difference, I think it comes down to whether
> origin/master reflects the development work we are doing towards the next
> release, or whether it reflects the current stable release, and the
> origin/develop branch is the piece that we currently work off of.
> I haven't worked in either of the two paradigms, having developed
> server-based software for far too long, and I'd like a discussion on the
> pros and cons so I can visualize the consequences of each choice.
> J
> On Thu, Aug 9, 2012 at 9:52 AM, Matthias Friedrich <> wrote:
> > Hi,
> >
> > next small item on my release TODO list is a little bit of software
> > configuration management: We should decide on how we want to deal
> > with branches and tags.
> >
> > I don't have much experience with git, but I'd suggest a simple model
> > that most people are already familiar with. An old blog article of
> > mine describes this [1] (it's the second strategy discussed). There
> > are more complex models (people write lengthy papers about them) but
> > I've never really needed more than this. It's important to have clear
> > conventions that don't cause headaches or require advanced tool
> > mastery.
> >
> > Maven's release plugin supports this process perfectly, but I admit I
> > haven't used it with git before (with Subversion and Mercurial it
> > worked fine). If you want to take this approach, I'd document it on a
> > wiki page and post the link here for review.
> >
> > What do you think?
> >
> > Thanks,
> >   Matthias
> >
> > [1]
> >
> -- 
> Director of Data Science
> Cloudera <>
> Twitter: @josh_wills <>

View raw message