What should be the git workflow, so that it would be possible to painlessly support old versions of the project?

Question

git

Hello. We develop a framework and libraries for it, with the help of which we make projects. We use gitflow as the branching methodology , and everything was fine when the library versions went one after another. That is, 0.1, 0.2...0.40
But the realization came that the versions should be given correctly. We decided to use semver , and just rolled out big updates, broke backward compatibility. Versions went 1.0, 1.1, 1.2
Everything seems to be great - semver, gitflow - but suddenly they found a bug that exists in both 0.x and 1.x. And not all of our projects have the ability to transfer to the current branch of the library and will have to support 0.x for some time. Possibly long.
Gitflow does not regulate such behavior, as far as I understand. You can't create a hotfix from 0.40 and merge it into a master that already has 1.2.
I saw that in the node.js turnip on the github, separate branches are created for each release: release-v6.x, release-v5x. But I did not understand how they work with them.
Hence the question arises. Maybe someone knows and uses a methodology with which these problems are solved by themselves. And maybe there is even a tool that will do everything itself, like git-flow :)
I tried Google. I found a suggestion to move legacy releases to support/* but the idea seems so-so to me.

Answer 1

> I saw that separate branches for each release are created in the node.js turnip on github:
and
> the proposal to move legacy releases to support/*
is, roughly speaking, the same thing. well, in terms of git flow, you will not have one master, but a master for each version.
He himself said that the changes are breaking and incompatible .. how are you going to store them in one master?

Answer 2

But after all, according to gitflow, support branches are just designed to support old releases without merging into the master.