Skip to content

Pre release

A new minor version of the Agent is released every 6 weeks (approximately). Each release ships a snapshot of integrations-core.


Ensure that you have configured the following:

Before Freeze

  1. Make a dependency update PR 1 week before freeze:

    • Create a new branch
    • Run ddev dep updates --sync
    • Run ddev dep sync
    • Create a PR with the updated dependencies
    • If CI is failing and there are compatibility reasons, investigate the errors. You may have to add the dependency to the set of IGNORED_DEPS and revert that change.


    Revert the changes and rerun ddev dep updates --sync with the --check-python-classifiers flag if there are many CI failures on your PR. Running it with the flag will not update a dependency to the newest version if the python classifiers do not match the marker. Although sometimes classifiers are inaccurate on PyPI and could miss a version update, using the flag does reduce errors overall.

  2. Update style dependencies to latest versions (except if comments say otherwise) via PR. Example: ISORT_DEP, BLACK_DEP, etc.

  3. Check that the master, py2 and base_check builds are green.


At midnight (EDT/EST) on the Friday before QA week we freeze, at which point the release manager will release all integrations with pending changes then branch off.


  1. Make a pull request to release any new integrations, then merge it and pull master
  2. Make a pull request to release all changed integrations, then merge it and pull master
    • Get 2+ thorough reviews on the changelogs. Entries should have appropriate SemVer levels (e.g. Changed entries must refer to breaking changes only). See also PR guidelines.
    • Consider x-posting the PR to Agent teams that have integrations in integrations-core, so they can check relevant changelogs too.


Update PyPI if you released datadog_checks_base or datadog_checks_dev.


  1. Create a branch based on master named after the highest version of the Agent being released in the form <MAJOR>.<MINOR>.x
  2. Push the branch to GitHub



git tag <MAJOR>.<MINOR>.0-rc.1 -m <MAJOR>.<MINOR>.0-rc.1
git push origin <MAJOR>.<MINOR>.0-rc.1

QA week

We test all changes to integrations that were introduced since the last release.

Create items

Create an item for every change in our board using the Trello subcommand called testable.

For example:

ddev release trello testable 7.17.1 7.18.0-rc.1
or if the tag is not ready yet:
ddev release trello testable 7.17.1 origin/master

would select all commits that were merged between the Git references.

The command will display each change and prompt you to assign a team or skip. Purely documentation changes are automatically skipped.

Cards are automatically assigned to members of the team.

Release candidates

The main Agent release manager will increment and build a new rc every day a bug fix needs to be tested until all QA is complete.

Before each build is triggered:

  1. Merge any fixes that have been approved, then pull master
  2. Release all changed integrations with the exception of datadog_checks_dev

For each fix merged, you must cherry-pick to the branch:

  1. The commit to master itself
  2. The release commit, so the shipped versions match the individually released integrations

After all fixes have been cherry-picked:

  1. Push the changes to GitHub
  2. Tag with the appropriate rc number even if there were no changes

After the RC build is done, manually run an Agent Azure Pipeline using the release branch, and the latest RC built. Select the options to run both Python 2 and Python 3 tests. This will run all the e2e tests against the current agent docker RCs.


Image for Windows-Python 2 might not be built automatically for each RC. In order to build it, trigger the dev_branch-a6-windows job in the datadog-agent Gitlab pipeline building the RC (link shared by the release coordinator).


The Agent Release Manager will post a daily status for the entire release cycle. Reply in the thread with any pending PRs meant for the next RC and update the spreadsheet PRs included in Agent RCs.


Each release candidate is deployed in a staging environment. We observe the WARN or ERROR level logs filtered with the facets Service:datadog-agent and index:main and LogMessage to see if any unexpected or frequent errors start occurring that was not caught during QA.

Release week

After QA week ends the code freeze is lifted, even if there are items yet to be tested. The release manager will continue the same process outlined above.

Notify the Agent Release Manager when code freeze ends.

Last update: October 1, 2021