+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 <[email protected]> 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>
