Correcting bugs in old releases in a workflow as described by Adam Dymtruk ("branch per feature")

Question

I read the Adam Dymitruk git workflow and it all makes sense.

The only thing I can not find is fixing errors in older versions. Depict the "master" branch with tags in 7.0, 7.1, 7.2, 7.3, 7.4, 7.4.1, 7.4.2, 7.8, 8.2 and the most recent 8.3

Version 7.2 is in production for a specific client, and the error has been found and needs to be fixed.

The correction in 8.3.1 and moving the client from 7.2 to 8.3.1 is unacceptable to the client.

So, is there a recommended workflow for this?

I could create a fork of the leading branch from tag 7.2, call this release of branch-7.2.x, then process “release-7.2.x” as one relates to the main branch — create a function branch (72bug) from the baseline, fix the error, and etc., And ultimately merge the function branch into "release-7.2.x", make the assembly, make the 7.2.1 tag and put it into operation. "release-7.2.x" will then live forever, like the wizard, so any corrections for 7.2.x can be made in version 7.2.x.

Of course, you do not want to lose the patch from 7.2 for the current work, so you can create a branch with the current base base (8.3) and combine the error branch (72bug) into this function branch. This function branch will be processed like any other function for the current cycle / sprint. Thus, at the end of the cycle, the new baseline (8.4) will contain error correction.

How did other people using Adam's workflow view this situation?

Answer 1

If you can’t transfer the client to the current version, then there really is no need to start a new branch with the 7.2 tag.

Instead of fixing the error in the 72bug branch and merging it with both the release-7.2.x branch and the current function branch, I would suggest fixing the error in the current function branch, and then using git cherry-pick to back up the correction to the release branch -7.2.x. This will help keep your history clean, so your current development does not seem to be dependent on the old version simply because of the needs of one client.