Skip to content

Pull requests


Title

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.

For the base package and dev package, you may want to prefix the title with the component being modified e.g. [openmetrics] or [cli].

Changelog label

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 changelog/<TYPE>.

For changelog types, we adhere to those defined by Keep a Changelog:

  • Added for new features or any non-trivial refactors.
  • Changed for changes in existing functionality.
  • Deprecated for soon-to-be removed features.
  • Removed for now removed features.
  • Fixed for any bug fixes.
  • Security in case of vulnerabilities.

Caveat

If you are fixing something that is not yet released, apply changelog/no-changelog.

Separation of concerns

Every pull request should do one thing only, for many reasons:

  1. 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.
  2. 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.

Merges

We only allow GitHub's squash and merge, for 2 reasons:

  1. To keep a clean Git history
  2. Our release tooling relies on commits being suffixed with the PR number in order to list changes between versions

Last update: March 3, 2021