Github: https://github.com/semantic-release/semantic-release/
We follow ESlint version conventions. They base their release numbers on git commit tags (tags are the first word in the commit message followed by a colon, eg: Fix: bug in main menu). These tags are: Breaking:, Update:, New:, and Fix:, and they should always be followed by a commit message.
Here is an example of the release type that will be done based on a commit message:
| Commit message | Release type |
|---|---|
Breaking: change class name for all EOS icons |
Major Release - a version that will break something in the user application after updating the package |
Update: change design of bootstrapping icon |
Minor Release - a version that changes things in the package without the need from the user to modify the code base |
New: create a login icon |
Minor Release - a version that adds new components that won't damage the existing ones |
Fix: remove 1px space in systems icon |
Patch Release - a version that won't break anything or add any new feature after updating, just fixes a bug |
More information about semantic releases: https://semver.org/
We should continue creating normal commits in our branches, with the exception that if the card has a request from PO to create a release, then we need to modify the commit message of the Pull Request (all normal commits continue being the same).
PO will request the type of release for the PR: Patch, Minor, Major.
When you open a PR and save it, you will see the following:
Clicking on "Modify commit message" opens an input field that will let you modify the normal Merge branch XXX into master type of commit message of PRs. There, you need to modify the commit message (when required by the PO in the card) for the type of release this PR should create, for example:
That will create a Minor release when merged into master.