This project uses Release Please from Google to automate the release process. The tool handles versioning and changelog generation based on commit messages.
To ensure releases are generated correctly, we follow the Conventional Commits specification. Commit messages should be structured as follows:
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (white-space, formatting, etc.)
- refactor: A code change that neither fixes a bug nor adds a feature
- perf: A code change that improves performance
- test: Adding missing or correcting existing tests
- build: Changes that affect the build system or external dependencies
- ci: Changes to our CI configuration files and scripts
- chore: Other changes that don't modify src or test files
- revert: Reverts a previous commit
Example:
feat: add new workflow to handle peppermint
When introducing breaking changes, follow these steps to ensure a new major version is released:
- Prefix the commit message with
BREAKING CHANGE:: Indicate that the commit introduces breaking changes. - Describe the breaking change in the commit message: Provide details about what changes are being made and how they affect existing functionality.
- Merge the commit: Once the breaking change commit is merged,
Release Pleasewill automatically create a new major version.
Example commit message for a breaking change:
feat!: add new workflow to handle peppermint
BREAKING CHANGE: This update changes the way the Datadog monitor module interacts with the API, requiring updates to existing configurations.
The ! after feat indicates a breaking change, and the BREAKING CHANGE: section provides details about the change.