Say you are currently at version 3 of a product, and so your next version is 4. But you have features which are going to take much longer to develop than your release cycle, for instance wont be ready till version 5, (could be even longer). What is the best way to deal with this problem in git-flow? It seems to me that this work-flow doesn't really allow for this sort of thing. There is no real notation of the release after the next release.
Where I use to work we had a branch for the next release i.e. release/4 in the example above. And the master branch would be for the next release after that i.e. release/5. Features that would not be in version 4 but version 5 would be developed off the master branch. Feature branches off release/4 would be merged back into release/4 (which would be an update if version 4 had been released) and then master, (though it wasn't a big problem if you forgot to merge into master as well because the next person if they remembered would do it for you.)
When we moved onto the next release we would branch off master again i.e. create a release/5 branch. Features to be in release/5 would have branched off release/5, anything to be done in release/6 would be on the master, and so on.
I did like this workflow for this scenario because it made it easier to develop time intensive features, but still have the intent of being release aware. I am interested in strategies how this be achieved using modifications to git-flow?
If you can, you could consider a "git workflow" instead of gitflow.
I present it in "Handle git branching for test and production"
The idea is to have ephemeral 'next' branches (one for v4, one v5 or later), that you recreate after each release.
In them, you merge your feature branches you want. But if those feature branches are ready for the next release, you don't merge the 'next' branch to release (like you do in gitflow when merging develop to release). You merge the feature branch itself to release.
That way, you can manage the lifecycle of those long-term feature as you want, and validate them in integration with ohter in the appropriate (v4, v5, ...) next branch of your choice.