Releasing

This document summarizes the process of doing a new release of this project. Release can only be performed by Datadog maintainers of this repository.

Schedule

This project does not have a strict release schedule. However, we would make a release at least every 2 months.

No release will be done if no changes got merged to the master branch during the above mentioned window.
Releases may be done more frequently than the above mentioned window.

Check and upgrade dependencies where it applies and makes sense. Example
- Create a distinct pull request and test your changes since it may introduce regressions.
- While using the latest versions of dependencies is advised, it may not always be possible due to potential compatibility issues.
- Upgraded dependencies should be thoroughly considered and tested to ensure they are safe!
Make sure tests are passing.
- Locally and in the continuous integration system.
Make sure documentation is up-to-date and building correctly.
Build the package locally (e.g. python3 setup.py sdist), install it into a fresh virtualenv and test the changes that have been made since the last release.

Our team will trigger the release pipeline.

See changes ready for release by running ddev release show changes . at the root of this project. Add any missing labels to PRs if needed.
Run ddev release changelog . <NEW_VERSION> to update the CHANGELOG.md file at the root of this repository
Commit the changes to the repository in a release branch and open a PR. Do not merge yet.
Bump the version in datadog/version.py and push it to your changelog PR. Example
Merge the PR to master.

Create the release on GitHub. Example
A github action will kick off that builds and publishes this tag to PyPI. Confirm the release is available
Bump the version again in datadog/version.py to a dev version (e.g. 0.34.0 -> 0.34.1.dev), open a PR and merge it to master.