The release command uses the title of pull requests as-is to generate changelog entries. Therefore, be as explicit and concise as possible when describing code changes. For example, do not say
Fix typo, but rather something like
Fix typo in debug log messages.
As each integration has its own release cycle and changelog, and every pull request is automatically labeled appropriately by our CI, there is no need include the integration's name in the title.
Our labeler will automatically detect if changes would not impact shipped code and apply
changelog/no-changelog. In all other cases, you must manually apply
For changelog types, we adhere to those defined by Keep a Changelog:
Addedfor new features or any non-trivial refactors.
Changedfor changes in existing functionality.
Deprecatedfor soon-to-be removed features.
Removedfor now removed features.
Fixedfor any bug fixes.
Securityin case of vulnerabilities.
If you are fixing something that is not yet released, apply
Separation of concerns¶
Every pull request should do one thing only, for many reasons:
- Easy Git management - For example, if you are editing documentation and notice an error in the shipped example configuration, you should fix the error in a separate pull request. Doing so will enable a clean cherry-pick or revert of the bug fix should the need arise.
Easier release management - Let's consider how the release command would handle the case of making a code change to multiple integrations.
- If one of the changes only fixes a typo in a code comment, that integration will still be released as indicated by the label.
- If both changes should indeed be released but they do different things, only one integration's changelog entry would make sense.
We only allow GitHub's squash and merge, for 2 reasons:
- To keep a clean Git history
- Our release tooling relies on commits being suffixed with the PR number in order to list changes between versions