Antrea Release Process

    1. For a minor release On the code freeze date (typically one week before the actual scheduled release date), create a release branch for the new minor release (e.g release-1.4).

      • after that time, only bug fixes should be merged into the release branch, by cherry-picking the fix after it has been merged into main. The maintainer in charge of that specific minor release can either do the cherry-picking directly or ask the person who contributed the fix to do it.
    2. Open a PR (labelled with kind/release) against the appropriate release branch with the following commits:

      • a commit to update the . For a minor release, all significant changes and all bug fixes (labelled with action/release-note since the first version of the previous minor release should be mentioned, even bug fixes which have already been included in some patch release. For a patch release, you will mention all the bug fixes since the previous release with the same minor version. The commit message must be exactly "Update CHANGELOG for <TAG> release", as a bot will look for this commit and cherry-pick it to update the main branch (starting with Antrea v1.0). The process-changelog.go script may be used to easily generate links to PRs and the Github profiles of PR authors.
      • a commit to update as needed, using the following commit message: .
    3. Request a review from the other maintainers, and anyone else who may need to review the release notes. In case of feedback, you may want to consider waiting for all the tests to succeed before updating your PR. Once all the tests have run successfully once, address review comments, get approval for your PR, and merge.

      • this is the only case for which the “Rebase and merge” option should be used instead of the “Squash and merge” option. This is important, in order to ensure that changes to the CHANGELOG are preserved as an individual commit. You will need to enable the “Allow rebase merging” setting in the repository settings temporarily, and remember to disable it again right after you merge.
      • the Docker image has been pushed to dockerhub with the correct tag. This is handled by a Github worfklow defined in a separate Github repository and it can take some time for this workflow to complete. See this for more information.
      • the assets have been uploaded to the release (antctl binaries and yaml manifests). This is handled by the Upload assets to release workflow. In particular, the following link should work: https://github.com/antrea-io/antrea/releases/download/<TAG>/antrea.yml.
    4. After the appropriate Github workflow completes, a bot will automatically submit a PR to update the CHANGELOG in the main branch. You should verify the contents of the PR and merge it (no need to run the tests, use admin privileges).

    5. For a minor release Finally, open a PR against the main branch with a single commit, to update VERSION to the next minor version (with -dev suffix). For example, if the release was for v1.4.0, the VERSION file should be updated to . After a patch release, the VERSION file in the main branch is never updated.