This document summarizes the process of doing a new release of this project. Release can only be performed by Datadog maintainers of this repository.
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
masterbranch 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.
- Install datadog_checks_dev using Python 3.
- Setup PyPI, see the internal documentation for more details
- 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 theCHANGELOG.mdfile 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.pyand 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.pyto a dev version (e.g.0.34.0->0.34.1.dev), open a PR and merge it to master.