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 17:30:53 GMT
+1 for the SVN-style approach to releases Matthias outlined in his blog
post:  http://blog.mafr.de/2007/04/25/release-management/

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

> Hi Josh,
>
> On Friday, 2012-08-10, Josh Wills wrote:
> > 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?
>
> Yes, if you're maintaining more than one release line then you can't
> prevent merges flowing in multiple directions in general.
>
> When I get into a situation where I have to fix a bug on release
> branches 1.0 and 2.0 and the main line, I would fix it on 2.0 first
> because 2.0 is closer to main, making the merge easier. Then I'd
> try to merge from main to 1.0, unless they differ so much already
> that I have to re-implement the fix on 1.0.
>
> That is, unless external influences force me to do it differently.
> For example, if 1.0 is in production and 2.0 is just being tested
> by QA.
>
> Supporting multiple releases is generally unpleasant, no matter
> which workflow you use. I can remember we once had to support three
> release lines concurrently. No fun at all.
>
> Regards,
>   Matthias
>



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