Is "Cascade Merging" (Forward Porting) riskier than Backporting?

There is no difference in the risk of getting merge conflicts (regardless whether they are of syntactical or semantical nature) - this can happen by porting/merging forwards or backwards. Either the related code sections (directly and indirectly related sections) have changed between versions to a degree where porting/merging of the bug fix from one branch to another needs manual intervention - or they haven't.

So, which is the "easier direction"? As you noted, your line of development allows to use (half-automatic) cascading merges - that's simply because in your older maintenance branches, the only changes are bug fixes, and you typically want all of those changes in the newer branches up to the trunk (at least in a semantically equivalent fashion, assuming the bugs are still in there). That is often not true in the other direction - the trunk contains bug fixes and new features, and you want only the bug fixes to be merged/ported downwards - so there is more effort involved to sort the bug fixing changes/commits out (a.k.a. "cherry picking"). Note the saved effort in total is not that huge - the most effort is typically to resolve merge conflicts, and to test & debug each fixed branch.

Is forward merging clearly "the best" strategy? Well, lets think what happens before one starts to fix a bug. Someone has to stumble about a problem and report an error. Lets say your product has released versions 1.0, 2.0, 3.0 plus the trunk which is going to become the next 4.0. Now let us assume a user of version 2.0 files a ticket for something which might be a bug.

When I get such a ticket, first thing I usually do is trying to reproduce the error in my own environment. Maybe I should always use version 2.0 right from the start, but since the trunk is my active branch, readily checked out and compiled with debug information, what I often do in reality is trying to reproduce the issue in the trunk and in case it shows up there, debug, fix, and test it there first.

When I have understood the root cause of the bug, next thing I have to decide is: do we really need to provide this bug fix in the earlier versions? Knowing the root cause often allows me to suggest a workaround, which can be communicated to the users. Providing the bug fix only in version 4.0 might be a business decision: when the customer wants fixes even for minor bugs, you may want to motivate them to upgrade to the newest release.

In case the issue has some urgency and there is no sensible workaround, next branch to fix should probably be 2.0, since the user may be waiting for a fix (and maybe cannot easily upgrade to 3.0 or wait for 4.0). This will also happen when I cannot reproduce the bug in the trunk (which happens rarely, since bugs have the nasty habit of not vanishing as long as noone fixes them). Finally, I have to make a decision which other maintenance branches will need the bugfix, too, and I will merge it in any direction where it is required - downward to 1.0, and/or upwards to 3.0 and the trunk.

So in short, there are two "natural" branches where a bug fix is developed first, and from where the merging into other branches starts:

• the branch where the dev is most familiar with - often the trunk

• the branch where the user has reported the issue from

Of course, there can be reasons why you decide to start to fix another branch first. Maybe you know version 1.0 is in use by 10.000 users, version 2.0 only by 10, so the fix maybe more important for 1.0 even when the bug was reported in 2.0 (assumed it was not a bug introduced in 2.0 first).

Hence in the end, our decision in which branch we start fixing a bug, and in which direction we merge it, should not be primarily influenced by the availability of a cascading merge feature for forward merges. It should based on the criterion which branches really need the bug fix, and which of them most urgent. When 1.0 is among these branches, by chance, then starting there and using cascading merge to go forward is fine, otherwise not.

Porting forward implies that you know which version should receive each fix ahead of time so that you execute the fix on the right branch each time. For some build flows, this is true, but for many flows one does not want to continue updating the oldest version all the time. The highest priority changes are put on the oldest version. It may be useful to do the normal backporting approach, giving you time to see how far back it should be ported.

Cascade merging also seems tricky from a version management approach. It means that new features may only exist in the older versions until they are forward ported to the latest. Depending on your level of discipline, this has a very strong risk of creating a very fractured version history.

A key question should be who is consuming these patches? Individuals who are hanging back on old versions are less likely to want the patches immediately, compared to those who are staying up to date. On the other hand, if version 3.0 was a monumental achievement for your program and not many people have been excited to update to 4.13, it may make sense to apply patches where the dollars are, especially if your 3.0 community has signed maintenance contracts. Maybe this doesn't apply to OSS, but you get the idea.

If two branches both have unique commits on them. ie. developers have been working on them adding features etc. Then No, you can't say merging one way is better than the other.

But. will that be the case if you have a bunch of release branches that don't get touched except for say, updating packages when a new (non breaking change) version is released?

Likely you will be able to put the change on the oldest branch first and then merge it up into all the others. If you (or bitbucket) can automate it you might save a bunch of time.