Legitimize "support branch" support

[dabrahams]

Support branches are hugely important and serve a role that's a standard part of most branching models.
It's hard to see how they could go wrong.
When can they move from experimental to become first-class citizens?

Thanks

[robohack]

+1, as they say!

I envision being able to keep old "feature" branches and hotfix branches by renaming them to some other namespace ("done*"?), then being able to merge (or cherry pick) them onto support branches in order to back-port them to releases that are still being supported (or as the FreeBSD folks would say, "merge from current" aka "MFC")

A "git flow release finish PATCH_TAG_NAME" command should tag the support branch so that it can be checked out for build and test and burn.

[elhedran]

+1,

Its nice that there is some support for this, but I can't exactly push the support internally if everyone who runs the command sees a warning about not using it. What will it take to make it not-experimental?

Since most of the pages I've found online seem to think its only for 'big lazy customers' I think I better add some more information on why this is needed.

It all has to do with down-stream dependencies. You have your software tested, it works, it ships to customers. You find a bug in a library or tool you use to create your software. You do NOT want to do a major upgrade to fix the bug because the QA effort will be equally huge. You want a release from a support branch.

This is doubly true if that down-stream dependency is part of a large product still actively under development. Some projects are too large to be a single repository. If there is active development though this means API's will change and break. Without support branches there is no way to support this in a natural way. downstream dependencies can't just stop working because an upstream dependency changed. More so it may be that the API change won't make it into the over-all product, so stopping all work on previous releases is also unacceptable.

We are not talking about lazy customers. We are talking about situations where the upstream is in rapid flux and has downstream dependencies, or when there is a very, very large number of downstream dependencies and the cost of upgrading is non-trivial.

The best real-world example I can give off the top of my head is distributions and OS's. Microsoft didn't just stop releasing fixes for XP just because 95 came out. It took some time first.

Basically what I'm saying is if your project is larger than X, or has more customers than Y you need support branches.

[elhedran]

To put it another way,

"I'm happy to write code for this, what are the issues/features needing fixing/testing" before you would be happy to get rid of that EXPERIMENTAL warning.

[atian25]

+1

[joeholdcroft]

+1