Post release¶
Finalize¶
On the day of the final stable release, tag the branch with <MAJOR>.<MINOR>.0
.
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
See more options for ddev agent changelog
and ddev agent integrations
.
Run the following commands to update the contents:
ddev agent changelog -w -f
to update the existingAGENT_CHANGELOG
fileddev agent integrations -w -f
to update the existingAGENT_INTEGRATIONS
file.ddev agent integrations-changelog -w
to add Agent version to existingCHANGELOG.md
releases of integrations.
Create a pull request and wait for approval before merging.
Patches¶
Important
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>
. Oncemaster
is unfrozen, releasingall
may result in unwanted and unshipped changes to the release branch if new changes are introduced. Useddev release make check1 check2
instead if releasingcheck1
andcheck2
.
-
Releases from the
master
branch 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
<MAJOR>.<MINOR>.<PATCH>-rc.1
. -
After the release has been made, make a PR to
master
with the updates toCHANGELOG.md
, agent release requirements, and__about__.py
of 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__.py
is higher onmaster
than in the release branch, only update theCHANGELOG.md
in this PR.Important
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
master
. -
Finally, if a patch release was performed, follow the same steps to finalize the release.