We use lerna to manage the release process for our SDK and SampleApp. It has an option for conventional commits and we use it on every commit and pull request title so we can have automatically generated tags and changelogs.
We use Angular's spec for conventional commits and enforce it on every commit with Husky + commitlint.
Also, we enforce that our pull request titles follow the spec because we only count merge from pull requests and BREAKING CHANGE flagged commits when bumping a version or creating the changelog. It means that your regular commits wont trigger a version bump or appear in the changelog unless they have a BREAKING CHANGE flag. Instead, only the merge commits from pull requests will be used.
Please follow the spec when adding breaking changes. Have in mind that the ! in the commit message is not really supported from lerna yet so avoid that and just add the BREAKING CHANGE: flag to the commit body. As explained in the last section, you have two ways to trigger breaking changes: On commit level and on pull request level. The recommended is to do it at commit level in order to be more specific on whats breaking and which commits is generating the breaking change, but if thats not possible for some reason, you need to add it to the pull request merge body.
Please have in mind that the only line you have to add is the selected one. Github already takes care of adding the PR title to the body of the merge commit.
All pull requests should point to the develop branch. Everytime it is updated, a new next version is created and released to npm using the latest commit sha.
Everytime we want to push things to master, we should create a pull request from develop to master. When that PR is opened/updated, a comment will be
added/updated containing the changelog that will be generated by merging that PR. This is useful for knowing whats going to be released if we decide to
press the merge button. By doing that, a release candidate tag is created and flagged with the rc tag on npm. Also, a merge back pull request is created from master to develop.
Once the release candidate is well tested and approved, the manual release workflow can be triggered through the Github actions UI. It should always be pointed
to master and it will graduate the latest release candidate to an actual release, flagging it with the latest tag on npm. Also, a merge back pull request
is created from master to develop.