Enforce GitLabFlow branching strategy

[jescalada]

Given all the issues we've been having with delayed releases and extensive merge conflicts (see #1442), we decided to improve our branching process to mitigate these problems in the future.

On our last community call (#1454) we decided that a "GitLabFlow" strategy (simple explanation here) strikes the best balance between release speed and maintenance cost compared to GitFlow and GitHubFlow.

Describe the solution you'd like

Branching Strategy

We can start using GitLabFlow branching from v2.0.0 onwards. This would require making a release/2.1 branch out of main once all the issues in the v2.1 milestone (WIP) are completed. Once the release branch is created, only bugfixes should be cherry-picked and merged into the release branch, everything else goes into main and waits for the next release.

Finally, we make each release from its respective branch. The release date could be the same as the milestone "deadline" in order to set a proper release cadence.

Release Planning

I believe issue-based planning (as proposed in #1452) adds too much maintenance overhead vs. simply using milestones which support most of what I proposed except detailed status display. From now on, minor and major releases can be tracked via milestones, which ought to be restricted in scope to prevent the scope issues we had previously. Once all issues are closed, we make the release branch and scope is officially frozen.

Describe alternatives you've considered
GitHubFlow (what we've been doing) is too simple and has been the cause of our massive merge conflicts and PR maintenance costs, meanwhile GitFlow adds too much complexity for a library that doesn't benefit much from production and staging branches.

Checklist

• Achieve consensus on branching strategy
• Document branching and release process
• Make release/2.0 branch and release according to new strategy

@finos/git-proxy-maintainers Do we all agree on this release/branching process? Let me know if anything should be amended or done differently.

[coopernetes]

I get the integration challenges with trunk-based development as well as scope creep so I'm generally supportive of this change. I added some details and a few Mermaid diagrams (feel free to reuse them here) in this gist to demostrate how this will look: https://gist.github.com/coopernetes/b8f41222c2498267bbc7a93a357b3736

Any thoughts on the casade-based merge strategy? I quite like that one personally and is largely the same outcome as cherry picking fixes across release branches.

[coopernetes]

That said, I think now that we're close to 2.0 with a ton of foundational work completed and technical debt paid down (only thanks to all the amazing work done by the team & contributrs from the community!!), I believe we'll be able to have a lot more frequent, incremental releases going forward. Having those features clearly scoped and frozen in a release branch is better for long term maintainability.