We use workspaces and semantic-release to manage the release process for our SDK and SampleApp. It enforces conventional commits 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 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.
If you've released something you were not supposed to and want to remove that release from npm, remove the git tag and then rollback the changes, you have a few options:
Cleanest way is to just reset the main branch and remove the last few commits, so the ideal is just do reset and force-push.
If you want some of the newest commits but want to remove older ones you can just revert the commit with git revert MERGE_PR_COMMIT_HASH. Please have in mind that in case your merge commit contains a commit with a breaking change flag, you need to revert that commit BEFORE reverting the PR 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 main, we should create a pull request from develop to main. 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 main 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 main 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 main to develop.