Description
Our current release workflow is described here: https://github.com/hvac/hvac/blob/develop/CONTRIBUTING.md
The way our repository is structured, we have a main branch, which is not our default branch, and we have a develop branch which is our default branch and PRs are opened against the develop branch.
When we are ready to release, we do it by opening a PR to bring the changes in develop into main, and we rebase those commits onto main.
We also have "release drafter" updating a draft release, and we have to manually copy/paste out of that into a changelog, and push those commits.
- https://github.com/hvac/hvac/blob/develop/.github/workflows/release-drafter.yml
- https://github.com/release-drafter/release-drafter
Proposal
In my opinion, this process is a bit more complicated than it needs to be.
I'd like to propose the following:
- We remove the
developbranch, makemainthe default branch, and all PRs are open againstmain - When PRs are merged, they are merged directly into
main(squash & merge) - Releases are still done similarly: a tag in the
mainbranch (probably still with a "release PR" of some sort)
Outstanding questions / uncertainties
I'm not very familiar with release drafter's full capabilities, so I need to see how it might work with this type of workflow, and that will determine the particulars of doing actual releases.
Other thoughts
- I'm wondering if this might solve our long-standing issue with "indirect" coverage changes -- on every PR the coverage appears to be decreasing usually, in files that have nothing to do with the PR. Occasionally, this doesn't happen on at least one push, but it happens on most, and it can change within the course of the PR, despite none of those files being touched. I haven't been able to find the definitive reason for this, so it's a stretch as to whether the current git flow is related, however I think at a minimum it will be easier to diagnose and troubleshoot.