18

I've migrated several of my projects over to the git flow work flow, and I'm loving it. However, I haven't found a best practice that keeps things flowing as smoothly when working with a project in which more than one major version is maintained at a time.

Specifically, I'm not maintaining a "free version" and a "paid version" or any other parallel model, I'm talking about a project in which Version 1 gets released, and remains supported with minor versions (1.1, 1.2, etc.) until Version 3 has been released, at which point 2 and 3 would be maintained, until 4 is released...you get the idea.

How have you, or would you, maintain two or more supported versions of a project at once in a gitflow workflow?

Improve this question
  • Don't have any examples atm, but projects I know of used separate repositories for different major versions, and backport patches from one to the other. – ProdigySim Apr 12 '11 at 18:55
  • @ProdigySim: Thanks for the data point, but is it just me or would that add a certain amount of overhead to track and manage? – HedgeMage Apr 12 '11 at 18:56
  • @ProdigySim I suspect that those projects didn't use a tool with the branching and merging capabilities of git. – Rein Henrichs Apr 12 '11 at 20:34
  • @Rein They use Mercurial. I don't think branching would be very clean in terms of tracking parallel major-versions of software. – ProdigySim Apr 12 '11 at 21:04
  • Then my suspicion was correct. And yes, it is quite clean if your tool supports it properly. git and the Linux kernel both do it this way. – Rein Henrichs Apr 12 '11 at 21:06
10
+150

man gitworkflows, the grand daddy of the 'git flow' workflow, describes general git workflow guidelines; the use of pu, next, master and maint branches; and how maint is managed. If you have multiple maintenance branches, you can name them, for instance, maint/1.x, maint/2.x and so forth.

The key is not so much how to use the git commands, but how to build a reasonable process. Decide what things are important to you (ease of backporting?) and build (and document) a workflow that satisfies those constraints.

Improve this answer
  • But does this answer the question? Namely, does git-flow support a flexible release model as described in the question, or does one revert back to basic git commands? ("gitworkflows" describes basic git workflow usage, pre-git-flow.) Git-flow was created (ostensibly) to simplify git merge/branch processes, so teams (with varying degrees of git-fu prowess) could focus on coding and avoid time-consuming "mis-mergerment" mistakes. Is it possible w/ git-flow to maintain and develop v1.2.{1,2,3,..} at the same time as v2.5.{1,2,3,...}? Perhaps w/ long-term release branches? Or master1, master2,...? – michael Jun 11 '12 at 5:03
0

Basically, you would duplicate the master, release, and develop branches for every major version you are maintaining. How they interact with each other remains the same. For feature branches, just make sure to branch from the oldest branch you intend to merge back into, which prevents pulling in unwanted dependencies. Then when you merge your feature branch back in, you just do additional merges into each appropriate newer major version branch.

Improve this answer
  • 1
    Isn't the whole point of master to include every released version? – HedgeMage May 1 '11 at 6:43
  • @HedgeMage, in a more linear release cycle that's the case, but that's highly impractical for parallel major versions. – Karl Bielefeldt May 3 '11 at 6:29
  • This seems like the most practical solution, unless there is some tried-and-true trick using hotfixes or such that i'm not aware of. I've been searching for a way to introduce git-flow and still be able to (as an unfortunate prerequisite) keep our existing release model, where we have to maintain/develop older releases (not just hotfixes). So v5.1.x will stick around (w/ new features added, bugs fixed, etc) a couple years after v6.1.x is released. About 2-3 major versions supported and developed at any given time. But bug fixes need to be applied to each version where the bug exists. – michael Jun 11 '12 at 5:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.