Date: 2022-04-05 (yyyy-mm-dd)
Accepted
As discussed briefly in deployment-flow, we will need a strategy for our versioning and releases.
We will use the industry standards "gitflow" to handle release branching above our git-workflow. You can read more about gitflow here and here. As shown below, the raft team will merge any relevant feature branches of the form feat/###-branch-description into the develop branch. From this branch, we will split off a release-specific branch of the form release/v#.#.#. This release branch can be merged to HHS/TANF-app:main which will deploy to staging site for review and testing. Once this release is fully ready, HHS/TANF-app:main will be merged into HHS/TANF-app:master which should contain only finalized merge commits of the release versions and will deploy to production.
Source: https://nvie.com/posts/a-successful-git-branching-model
For versioning, we will be adopting semver for our versioning strategy. Semver is not just a rubric for incrementing our numbers but has a technical meaning for backwards compatibility of our API(s) and codebase generally. As we gear up for production, we will be releasing v1.0.0 which serves MAJOR version 1 with no extra features. As detailed in the semver link, minor and patches updates will be backwards compatible. Feature sets that add functionality will increment the minor version and bug fixes will increment the patch version. Each version of our codebase will require an entry into the changelog file for a high-level overview of what was added, changed, or obsolesced. This changelog will be stored here.
Changelog entries must of the form with newer releases above older:
## \[#.#.#\]\(https://github.com/raft-tech/TANF-app/releases/tag/v#.#.#\) - YYYY/MM/DD
### Added
### Changed
### Removed
### Fixed
The link to the release page will generated from the creation of releases here.
Hotfixes should always be the exception but may become necessary in a production environment for a severe bug or breakage and should essentially be a user-stopping emergency. As you'll note below, the hotfix will be split directly from the master branch and merged directly back in with a new version with the patch updated. We will also need to update the changelog and have this new hotfix merged and tested within the develop branch. If the issue is not a show-stopper, it should be treated as a regular feature would be and created as a bug ticket and branch (e.g., bug/####-branch-description).
Source: https://nvie.com/posts/a-successful-git-branching-model
- We have an established well-known set of processes and notation for release branching and versioning.
- We will understand based on a label what changesets will be breaking in nature.
- New notation and process to learn for the team