Updated Release Process Proposal

Goals of this plan:

Eliminate interruptions to an in-progress release
Move towards a trunk based continuous delivery model (https://trunkbaseddevelopment.com/)
Avoid disruption to engineers

New Concepts

Checkout latest main
Create a new release branch in the format release-v0.1.0
Publish release branch with git push -u origin release-v0.1.0
Confirm with all contributors to the release that the release branch is ready
- Contributors can be found with git rev-list v0.0.0..HEAD where v0.0.0 is the previous release
- Fixes can be cherry picked from main into the release branch during this time
Open a PR in GitHub from release-v0.1.0 to prod
Once merged, create a release in Github targeting prod with a new tag in the format v0.1.0.
Delete the release branch

Create a hotfix branch in the format hotfix-v0.1.1 from the tip of prod
Cherry-pick the fix commit from main into the hotfix-v0.1.1 branch
Open a PR in GitHub from hotfix-v0.1.1 to prod
Once merged, create a release in Github targeting prod with a new tag in the format v0.1.1.

main is the source of truth for the codebase
Release branches and hotfix branches are never merged into main
Any changes to a release or hotfix branch must be done by cherry-picking commits from main.
- This means you can not push changes to release or hotfix branches directly.
main should be considered to as stable. Do not push changes to main that are not ready to be in prod.
- If a feature isn't ready for release, consider putting it behind a feature flag.
Task branches should be small and committed frequently.
Merges into prod should not be squash merges. This ensures we can determine contributors since the last release. Merges into main can still be squashed.