In the release plan thread, there has been discussions about proposing a branching model that might be sustainable. This is my attempt at that.
We have two main branches in an ongoing way;
- master - main development and features go here.
- 2.0 - the stable branch that accepts bug fixes. This would change to 2.1 when that is ready for beta only type fixes.
This would allow riskier features to be applied to master, and even complex bug fixes that seem like they might cause problems for stable.
2.0 would, until release have all required fixes for release added. After each fix, a pull request would merge those changes into master.
2.0 after release would be used to reproduce issues seen in 2.0 stable and fixes would be applied to master if required (eg not already fixed there), and when determined to be important enough to fix in 2.0, then a separate pull request made for 2.0 to make the appropriate fix.
Overhead of maintenance on 2.0 branch reduces as time goes on “if we are really stable”, and work can focus on master. As we want relative stable before release, master can test more things quickly. Like DB performance rewrites, progressing on .net6 and improving testing. All without breaking up the plan for a canary on 2.0.
If some specific change in master is stable for a period of time, during beta of 2.0 it may be backported to 2.0 branch. I’m thinking of the benefits of local db performance issues or addition of new cloud endpoints as examples.
Depending on developer resources, the support timeline for 2.0 (stable) can be determined. One example might be
- 6 months performance fixes
- 12 months non-critical bug fixes
- 12 months after next major release for data-loss bugs.
Those timelines depend a bit on release frequency and how many issues are being submitted.