incubator-crunch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Wills <jwi...@cloudera.com>
Subject Re: Release preparations: Branching model
Date Fri, 10 Aug 2012 16:35:37 GMT
Hey Matthias,

Thanks for humoring me on this. It doesn't seem to me that there is any way
to avoid the multi-directional merge issue, right? If we have two releases
and master branch and we find a bug that needs to be fixed in the first
release, we still have to do a couple of complex merges to fix it on 1.0
and 2.0 and master, right? What does that workflow look like?

J

On Fri, Aug 10, 2012 at 7:35 AM, Matthias Friedrich <matt@mafr.de> wrote:

> Hi,
>
> 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.
>
> Regards,
>   Matthias
>
> 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.,
> >
> > http://nvie.com/posts/a-successful-git-branching-model/
> > https://github.com/nvie/gitflow
> >
> > 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 <matt@mafr.de> 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] http://blog.mafr.de/2007/04/25/release-management/
> > >
> >
> >
> >
> > --
> > Director of Data Science
> > Cloudera <http://www.cloudera.com>
> > Twitter: @josh_wills <http://twitter.com/josh_wills>
>



-- 
Director of Data Science
Cloudera <http://www.cloudera.com>
Twitter: @josh_wills <http://twitter.com/josh_wills>

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