Use develop as the base branch when starting development. Follow our usual standard for branch names:
feature/*for new features.bugfix/*for bug fixes.chore/*for non-functional changes.
This repo uses semantic-release and conventional commit messages so prefix your commits with the appropriate change type if you want your changes to appear in release notes:
feat:when implementing a new feature.fix:when implementing a bug fix.chore:when making changes that do not affect the library functionality. "Chore" commits do not generate a new release.
When introducing a breaking change, add what has changed in the footer of the comment in the format BREAKING CHANGE: what has changed.
Check out examples in the documentation.
After done with your development, open a pull request to main.
Pull requests are merged with the "Squash and merge" option, so that the commit history is clean and the commit messages are meaningful. This means that the PR title will be used as the commit summary, thus it must follow the conventional commit message format described above. In case of a breaking change, add a ! after the type (e.g. feat!: ... or fix(Player)!: ...), and add the breaking change description in the end of the PR description.
Releases are done automatically as soon as changes are merged to main. Keep an eye in the Release action to follow the status.
A new version of the library is released when changes are merged to main. The release process will build and bundle the library, and publish it to npm.