Comments on: Release and branching strategies

By: Alex

Alex — Thu, 30 Oct 2008 15:02:19 +0000

@Paul, I agree with you but this is actually orthogonal to the process of branching for version management. Project/feature branches can happen in any place in the diagrams above between release points.

By: Paul Ayres

Paul Ayres — Thu, 30 Oct 2008 14:06:55 +0000

My take on best practise with regards to branching:

the main branch (or trunk) should be a stable reflection of production. where possible new projects should start off of the main branch and branch their work off on to a project branch. When the project is complete the new changes get merged back to the main branch (assuming that they went live).

By: Clint Shank

Clint Shank — Fri, 06 Jun 2008 15:12:43 +0000

Alex, Have you looked at Streamed Lines: Branching Patterns for Parallel Software Development? There's some pretty good information in there.

By: Eric Danker

Eric Danker — Thu, 05 Jun 2008 02:06:31 +0000

In regards to your last paragraph, I would be interested in learning more in a future post about the cumulative patches. That was a pretty sweet feature of the Metamatrix Server.

By: Alex

Alex — Wed, 04 Jun 2008 21:47:40 +0000

Yeah, I think the 1.0.0 tag on trunk is morally equivalent – but if your release closeout takes a while, it’s useful to branch early so some of the team can forge ahead. Depends on the situation.

I think the single line works till you get to a certain point of growth, then it’s not enough. Terracotta for example has grown to a point where we have a bunch of people in production and they need controlled release-specific patching, which is a natural evolution point.