How to make hotfixes for previous releases within the git flow?

Question

git

Let's say I created releases 1.0.0 and 1.1.0
Then users of 1.0.0 started complaining, and as a result, I need to build 1.0.1 with bug fixes. Because they do not want to switch to 1.1.0.
And how can I do this within the git flow?
I already have 1.1.0 on master.
If I make 1.0.1, then these changes will go to the master and develop branch. As a result, 1.1.0 will be overwritten! And with conflicts.
How to be?

Answer 1

If they don’t want to switch, then in fact they refuse support, threaten it, as an option, you can fork the project and maintain two projects, but you will have to fix the same bugs, which can be problematic, labor-intensive.
And what is the reason for the reluctance of a minor update, maybe you just need to competently sell?

Answer 2

Create a branch on release 1.0.0, make fixes and release in this branch, and maintain this branch in the future.

Answer 3

In my opinion, the question is more "political". than technical.
Supported versions should be clearly separated from unsupported versions.
So, for example, I have a project on python, and it was originally on Python v2.7, but at some point I got "support" for Unicode in the second python. Crawled to the 3rd, but because on some platforms there are problems with separate libraries for the third python, I separated the branch with the second python and announced - "only hotfixes for the second python branch".
The branch of the third python has already gone so far from the second, so the fixes for the second one in one simply won’t work there. Those. I simply can’t pour the same fix code into both branches (there, in the third python, all the code has already been redone to OOP, and in the second, there is a purely procedural approach).
This is how I see your situation. If people want a fix in the old version, then your right to do one of two things:
1. Refuse, saying that the old version is no longer supported,
2. Make a fix to the old version and separately make a fix to the new one (it is quite possible that one to one code for fix in the new one may differ from the fix in the stream)
And git is just a tool, how to use it - you have to decide based on the chosen policy for supporting older versions.