In git flow, there is a point where you decide to create a branch from the current develop being the new release. For example 1.7. Everthing that is ready to this point is considered beeing in that release, everything after this point is a new release (e.g. 1.8). Only bugfixes should go into the current release branch. The advantage is, that the current dev branch can still go on with further feature implementation without beeing "blocked". This seems to be a pretty linear flow where one release follows on another.
But how to handle successfully multiple releases in parallel using git flow?
The customer on the one hand wants to have a new version that have breaking changes (considered then as 2.x) but it is also not compatible with current main branch (1.x). On the same time the customer wants smaller features on the current 1.x branch to be released periodically until the 2.x is released.
Is git flow an approriate tool for this or should one consider switching to other strategies? If yes, which one is appropriate?
For example, how would on handle an additional 1.7 release with smaller features when there are already breaking changes on the current dev branch? I mean there are breaking changes which then can not be considered beeing a new 1.7 release. Would you just use the 1.6 branch as the base for the next 1.7? But how to handle features that are in 1.7 but should also be in the new 2.x branch (which might change a lot in the meanwhile)?