Releases and versioning

Applications should be versioned and release-able independently of one another. To help with this, this repository uses Conventional Commits to help manage semantic versions. Conventional commits has been chosen to help with:

1. Managing and bumping version numbers
2. Generating changelogs/release notes

Commit messages that are more visible will also result in better commit messages.

Conventional commits

Each commit message should follow the format:

Examples include:

# Bug fix
fix: update the account summary to show the correct balance

# Feature
feat: add option to mask account numbers

# Feature with scope
feat(login): add option to remember client id

# Breaking change
feat(accounts)!: return bsb as a string instead of a number

Versioning workflow

The diagram above shows the versioning workflow:

1. The application start with its current version number as defined in the package.json file (in this case, 1.0.0)
2. Changes are applied to the main branch via pull requests (multiple changes can be applied before the next step executes)
3. As changes are applied to main, the next semantic version number is calculated based on conventional commits, and a release candidate pull request is created for the next version including changelogs
   • If a pull request for the next version already exists, the release candidate is updated
4. When the release candidate pull request is merged to main, a release is created and the commit is tagged with the new version number
5. After the release has been created, release-able artefacts should be created, deployed, and launched as required