...
This current policy on branching and tagging makes two assumptions:
The project will not have the developer resources to actively develop more than one major release of a given product at a time.
The project may wish in rare cases to offer bug/security fixes for the previous minor version of a given product (e.g., if the given current release of the IdP is 3.2.X, than the developers might occasionally provide bug fixes for both it and 3.1.X).
Therefore, our products use the following branching and tagging practice:
Development of a new major or minor version is initially performed on the "main" branch.
When a new version is released, tags are created from wherever the work for that release was done.
A branch is not generally created. If after work begins on a new major/minor release, it becomes necessary to produce a patch release, a branch is then created from the original tag for the release being patched, and any fixes warranted from "main" are backported/merged back at that time.
Once the branch exists, bug fixes may need to be applied to both the branch for the previous stable minor release and "main".
This "late branching" policy should minimize the amount of time that bugs need to be fixed in two places.
...