Release guide
While committing everyone should evaluate the changes being added and prefix one of three labels to the beginning of the commit name:
- [breaking changes] - radically changes the api of the library (will be available only after the completion of work on 0.x.x versions)
- [feature] - new functionality
- [patch] - fixes/improvements to existing functionality
After the label comes a brief description of the changes (a description from which it will be possible to make a release note).
The result would be something like: [patch] resolved table view cell clicks issue.
Each commit message label corresponds to one of the version numbers MAJOR.MINOR.PATCH:
- [breaking changes] - MAJOR
- [feature] - MINOR
- [patch] - PATCH
Look for the highest label in the names of the commits and, according to it, select the version. Examples: Current version is 0.2.0, the highest tag is [patch] which means the next version is 0.2.1; if the highest tag is [feature] - the next version is 0.3.0. For a better understanding please check out semantic versioning.
Go to Actions → Release → Run workflow → Set the new version at "Version to bump to:" → Run workflow
- Create a new tag with the release version with the ‘v’ prefix, for example - “v0.2.2”.
- Choose the pom.xml version change as a target commit, its name would usually be something like "release 0.x.x"
- Set the title → generate the release notes (you can edit the structure to your taste) → publish the release
