After the main Agent release manager confirms successful deployment to a few targets, create a branch based on
master and run:
ddev agent changelog ddev agent integrations
Run the following commands to update the contents:
ddev agent changelog -w -fto update the existing
ddev agent integrations -w -fto update the existing
ddev agent integrations-changelog -wto add Agent version to existing
CHANGELOG.mdreleases of integrations.
Create a pull request and wait for approval before merging.
Only critical fixes are included in patches. See definition for critical fixes.
Releases after the final Agent release should be reserved for critical issues only. Cherry-picking commits and releases for the patch release is mostly similar to the process for preparing release candidates.
However, it's possible that from the time code freeze ended and a bugfix is needed, the integration has other non-critical commits or was released.
Given the effort of QA-ing the Agent release, any new changes should be carefully selected and included for the patch.
The next section will describe the process for preparing the patch release candidates.
Multiple check releases between bugfix release¶
There are two main cases where the release manager will have to release integrations off of the release branch: the freeze has lifted and changes to an integration have been merged after freeze and before a bugfix for an RC, or a patch release is required. To release an integration off of the release branch, perform the following steps:
Cherry-pick the bugfix commit to the release branch.
Prepare the release of the integration.
- Create a branch based off of the release branch.
- Run the integration release command on that branch.
- Make a pull request with that branch, then merge it to the release branch.
- Note: if there are multiple integrations to release, do not use
ddev release make all --exclude <INTGS>. Once
masteris unfrozen, releasing
allmay result in unwanted and unshipped changes to the release branch if new changes are introduced. Use
ddev release make check1 check2instead if releasing
Releases from the
masterbranch automatically trigger the release pipeline when the PRs are merged in. If you're releasing from a release branch however, you have to manually trigger the release pipeline by tagging the release:
`ddev release tag <INTEGRATION>`
Pull the latest release branch so your branch has the bugfix commit and release commit.
Tag the branch with the new bumped version
After the release has been made, make a PR to
masterwith the updates to
CHANGELOG.md, agent release requirements, and
__about__.pyof the integrations that were released on the release branch. Do not include the change to the in-toto file. If the current version of
__about__.pyis higher on
masterthan in the release branch, only update the
CHANGELOG.mdin this PR.
Do not merge this PR unless the release tag from the previous PR has been pushed or the release pipeline will incorrectly attempt to release from
Finally, if a patch release was performed, follow the same steps to finalize the release.