Version and release strategy

[thekaveman]

Since we're getting close to being live, now is a good time to implement a versioning and release strategy. This will help us talk about development and the application itself in more real terms like "These features are part of version XYZ".

Related Background

• Our deploys to production happen when we merge to the prod branch, via a GitHub Actions workflow.
• In Workflow: package and release on tag hashfields#8, we implemented automatic GitHub Releases in an Actions workflow when a new tag is pushed.
• https://github.com/reecetech/version-increment is an Action that can automatically increment a version number based on tags in the repository.

Proposal

A very rough outline of a process could look like:

1. Merge to prod to kick off a deploy to AWS, like now
2. After ^ deploy succeeds, increment the version number/tag using reecetech/version-increment
3. Push the new version number/tag
4. Make a new Release with the version number using softprops/action-gh-release (separate workflow runs when new tag shows up in GitHub)

Questions

1. Should we include a v prefix in the version numbers? Our consensus was no, and reecetech/version-increment doesn't support this anyway. See Support "v" prefix in incremented version reecetech/version-increment#8 for more.
2. Traditional semver scheme MAJOR.MINOR.PATCH, or alternatively, "calver" scheme YEAR.MONTH.RELEASE where RELEASE is the Nth release that month. Both are supported by reecetech/version-increment.

For versioning scheme, I kind of like calver for this application, given the other reporting requirements etc. that are monthly or month-based.

[thekaveman]

We've decided on using the calver scheme for all the Benefits related repositories.

• Our version numbers will look like YYYY.MM.RR, where YYYY is the year of the release, MM is the month and RR is the release number for that month
• We'll start our release numbers at 0 1 for each month
• We'll tag the prod branch for all releases

So the first tagged version will be 2021.12.0

[thekaveman]

In the proposal above, we'll keep 1-3 manual steps for now.

Step 4 could be interesting if we can integrate with a Conventional Commits based release notes generator.

[angela-tran]

If we were to use version-increment, we would want to be able to configure the branch to use as the "normal release" branch. We'd also want to be able to have the leading zero for the MONTH part.

[thekaveman]

We're going to start the version counter at 1 instead of 0 as this is a little more human-readable and non-technical.