I read a lot lately about different branching models and always ended up with Vincent Driessen's approach as the best setup for my development team.
One thing which bothers me is the problem when different versions deployed at different customers should get hotfixes. In this model each hotfix should be tagged and merged into master.
But this could imply the timelime on master gets messed up as the one hotfix would be merged on master after a newer version was tagged...?
Each customer has his own server. Customer A uses version 1.0, customer Bversion 1.1 and they only want hot fixes, no version upgrades. Does that answer your question?
Yes. You have a maintenance nightmare on your hands. I hope they're paying you well.
Basic Gitflow supports finishing up the current release while continuing to develop the next one. It does not support hotfixing multiple versions simultaneously. You will need to supplement it.
In basic Gitflow, hotfixes branch off the latest version tag on master. Once complete they are merged back into master and tagged to form a new release. They are also merged back into develop to incorporate the hotfix into future work. This works fine if you're only supporting one released version at a time.
To hotfix multiple releases, you need a branch for each older supported release. When you move from v1.1 to 1.2, you would create support/1.1 off the last v1.1.x tag.
Hotfixes are developed the same way as above, but you'd also rebase it into the release branches and tag the result. Rebase, not merge, because you don't want to drag along all the other new stuff.
Let's say you made a hotfix to v1.2 on the branch hotfix/123. Now you want to apply it to v1.1 and v1.0.
# Copy the hotfix commits to support1.1
# Tag it as v1.1.1
git rebase --onto support/1.1 v1.2 hotfix/123
git tag v1.1.1 support/1.1
# Copy the hotfix commits to support1.0
# Tag it as v1.0.1
git rebase --onto support/1.0 v1.2 hotfix/123
git tag v1.0.1 support/1.0
This will copy only the hotfix commits to each release branch. As this code was written on a newer version of the software, it is likely there will be conflicts. As you gain more versions the conflicts will get worse.
Anything is preferable to maintaining multiple releases. If it were me, before I committed to this I would ask why my customers want to stay on old versions, and if they're worth the extra time and money.
Usually its because they perceive their version to be "stable"; version 1.0 works for them and they don't see the need to upgrade and risk bugs and breaking features they rely on. Sensible for the short term, but disastrous for the long term. As they fall further and further behind, when they do need to upgrade it will become increasingly difficult.
Sometimes this view of stability is imagined, and sometimes it is real. Regression testing can ensure each new version does not break existing features. You could even survey your customers to find out what features they particularly rely on and ensure they are well tested.
You could provide them with test servers to try their systems on with the new version so they can be sure it will work.
Finally, as a business, ask if supporting old versions is worth the cost.