From b7b9e216a4fe813d83260a5a17aab991f0327e2b Mon Sep 17 00:00:00 2001 From: Florent Poinsard Date: Tue, 3 Oct 2023 11:01:24 -0600 Subject: [PATCH] Add release instructions for Milestones Signed-off-by: Florent Poinsard --- doc/internal/release/how-to-release.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/doc/internal/release/how-to-release.md b/doc/internal/release/how-to-release.md index 450127bd869..628beb151b7 100644 --- a/doc/internal/release/how-to-release.md +++ b/doc/internal/release/how-to-release.md @@ -87,6 +87,11 @@ That includes: > - There are two scripts in the website repository in `./tools/{ga|rc}_release.sh`, use them to update the website documentation. The scripts automate: > - For an RC, we need to create a new entry in the sidebar which represents the next version on `main` and mark the version we are releasing as RC. > - For a GA, we need to mark the version we are releasing as "Stable" and the next one as "Development". +- **Create a new GitHub Milestone** + > - Our GitHub Milestones is a good representation of all our ongoing development cycles. We have a Milestone for `main` and for all release branches. + > - After doing Code Freeze, we can create a new GitHub Milestone that matches the next development cycle. + > - **If we release a major version (v18.0.0-rc1):** we must create a `v19.0.0` Milestone. + > - **If we release a patch release (v17.0.3):** we must create a `v17.0.4` Milestone. ----- @@ -126,6 +131,11 @@ On the release day, there are several things to do: > - The docker image for `base`, `lite`, etc are built automatically by DockerHub. The k8s images however are dependent on these images and are required to be built manually. > - These images should be built after the `base` image has been built and available on DockerHub. > - To build and publish these images, checkout the new release tag that was just created and run `./release.sh` from the directory `./docker`. +- **Close the current GitHub Milestone** + > - Once we are done releasing the current version, we must close its corresponding GitHub Milestone as the development cycle for it is over. + > - **This does not apply if we are releasing an RC release.** For instance, if we are releasing `v18.0.0-rc1` we want to keep the `v18.0.0` milestone opened as development is not fully done for `v18.0.0`. + > - For instance, if we release `v18.0.1`, we must close the `v18.0.1` Milestone as the development cycle for `v18.0.1` is over. + > - When closing a Milestone, we need to look through all the PRs/Issues in that Milestone and re-assign a newer Milestone to them. -----