The current branching strategy on the repo relies on the use of 2 main branches.
- dev where the latest code is checked in.
- release which has a copy of the latest shipped version of the code.
I think we can do away with the release branch when we switch to targeting VS2022.
That is for these reasons:
- There will no longer be a single release as multiple extensions will not always be updated together. This means there is no single "current" release unless all extensions are updated at the same time and there is no need that they always should be.
- Its original purpose was to make it easier to ship minor updates or template updates if needed. We're doing away with template bundling and trying to make the release process faster and easier so the need to do a minor release as a quick fix is far less likely to be needed.
- Releases are all tagged so it should be easy to get the code from a specific release, if needed, without having a separate branch.
- Only having one branch makes branch management really simple and it's always clear where to merge a PR.
In an ideal world, I'd also rename "dev" to "main" but doing this would break all existing docs links and so should be avoided.
There may be reasons to keep the "release" branch that I am not aware of. (Possibly related to the [not publicly documented] release process.)
I'm also keen to hear reasons for other approaches to branching that could be more appropriate.
The current branching strategy on the repo relies on the use of 2 main branches.
I think we can do away with the release branch when we switch to targeting VS2022.
That is for these reasons:
In an ideal world, I'd also rename "dev" to "main" but doing this would break all existing docs links and so should be avoided.
There may be reasons to keep the "release" branch that I am not aware of. (Possibly related to the [not publicly documented] release process.)
I'm also keen to hear reasons for other approaches to branching that could be more appropriate.