Project: Vitess (App Definition and Development / Database)
File: how-to-release.md

In this section we describe our current release process. Below is a summary of this document. -- This section highlights the different pre-requisites the release team has to meet before releasing. The tool `gh` must be installed locally and ready to be used. You must have access to the Java release, more information in the section. You must be able to create branches and have admin right on the `vitessio/vitess` and `planetscale/vitess-operator` repositories. -- A new major version of Vitess is released every four months. For each major version there is at least one release candidate, which we release three weeks before the GA version. We usually create the RC1 during the first week of the month, and the GA version three weeks later. Before creating RC1, there is a code freeze. Assuming the release of RC1 happens on a Tuesday, the release branch will be frozen Friday of the previous week. This allows us to test that the release branch can be released and avoid discovering unwanted events during the release day. Once the RC1 is released, there are three more weeks to backport bug fixes into the release branches. However, we also proceed to a code freeze the Friday before the GA release. (Assuming GA is on a Tuesday) Regarding patch releases, no code freeze is planned. For each release, it is recommended to create an issue like to track the current and past progress of a release. It also allows us to document what happened during a release. -- This step happens a few weeks before the actual release (whether it is an RC, GA or a patch release). The main goal of this step is to make sure everything is ready to be released for the release day. That includes: Making sure Pull Requests are being reviewed and merged. > - All the Pull Requests that need to be in the release must be reviewed and merged before the code freeze. > - The code freeze usually happens a few days before the release. Making sure the people doing the release have access to all the tools and infrastructure needed to do the release. > - This includes write access to the Vitess repository and to the Maven repository. Preparing and cleaning the release notes summary. > - If the release does not contain significant changes (i.e. a small patch release) then this step can be skipped > - One or more Pull Requests have to be submitted in advance to create and update the release summary. > - The summary files are located in: `./changelog/.0/../summary.md`. > - The summary file for a release candidate is the same as the one for the GA release. > - Make sure to run `go run ./go/tools/releases/releases.go` to update the `changelog` directory with the latest release notes. Finishing the blog post, and coordinating with the different organizations for cross-posting. Usually CNCF and PlanetScale. This step applies only for GA releases. > - The blog post must be finished and reviewed. > - A Pull Request on the website repository of Vitess has to be created so we can easily publish the blog during the release day. Code freeze. > - As soon as we go into code freeze, if we are doing an RC, create the release branch. > - If we are doing a GA release, do not merge any new Pull

> - The guide on how to do a code freeze is available in the section. > - It is not advised to merge a PR during code freeze, but if it is deemed necessary by the release lead, then follow the steps in section. Create the Vitess release. > - A guide on how to create a Vitess release is available in the section. > - This step will create a Release Pull Request, it must be reviewed and merged before the release day. The release commit will be used to tag the release. Preparing the Vitess Operator release. > - While the Vitess Operator is located in a different repository, we also need to do a release for it. > - The Operator follows the same cycle: RC1 -> GA -> Patches. > - Documentation for the pre-release of the Vitess Operator is available . Update the website documentation. > - We want to open a preparatory draft Pull Request to update the documentation. > - There are several pages we want to update: > - : we must add the new release to the list with all its information and link. The links can be broken (404 error) while we are preparing for the release, this is fine. > - : we must use the proper version increment for this guide and the proper SHA. The SHA will have to be modified once the Release Pull Request and the release is tagged is merged. > - , , , and : we must checkout to the proper release branch after cloning Vitess. > - If we are doing a GA or RC release follow the instructions below: > - 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. -- On the release day, there are several things to do: Merge the Release Pull Request. > - During the code freeze, we created a Release Pull Request. It must be merged. Tag the Vitess release. > - A guide on how to tag a version is available in the section. Update the release notes on `main`. > - One Pull Request against `main` must be created, it will contain the new release notes that we are adding in the Release Pull Request. Create the corresponding Vitess operator release. > - Applies only to versions greater or equal to `v14.0.0`. > - If we are doing an RC release, then we will need to create the Vitess Operator RC too. If we are doing a GA release, we're also doing a GA release in the Operator. > - The Vitess Operator release documentation is available . Create the Java

> - Applies only to GA releases. > - This step is explained in the section. Update the website documentation repository. > - Review the Website Pull Request that was opened during the Pre-Release. > - The git SHA used in should be updated with the new proper SHA for this release. > - Merge the Pull Request. Publish the blog post on the Vitess website. > - Applies only to GA releases. > - The corresponding Pull Request was created beforehand during the pre-release. Merge it. Make sure _arewefastyet_ starts benchmarking the new release. > - This can be done by visiting . > - New elements should be added to the execution queue. > - After a while, those elements will finish their execution and their status will be green. > - This step is even more important for GA releases as we often include a link to arewefastyet in the blog post. > - The benchmarks need to complete before announcing the blog posts or before they get cross-posted. Go back to dev mode on the release branch. > - The version constants across the codebase must be updated to `SNAPSHOT`. Ensure the k8s images are available on DockerHub. 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. -- Once the release is over, we need to announce it on both Slack and Twitter. We also want to make sure the blog post was cross-posted, if applicable. We need to verify that arewefastyet has finished the benchmark too. Moreover, once the roadmap discussions are over for the next release, we need to update the roadmap presented in the Vitess website (https://vitess.io/docs/resources/roadmap/). We must remove everything that is now done in this release and add new items based on the discussions. -- In this example our current version is `v14.0.3` and we release the version `v15.0.0`. Alongside Vitess' release, we also release a new version of the operator. Since we are releasing a release candidate here, the new version of the operator will also be a release candidate. In this example, the new operator version is `2.8.0`. It is important to note that before the RC, there is a code freeze during which we create the release branch. The release branch in this example is `release-15.0`. The example also assumes that `origin` is the `vitessio/vitess` remote. Fetch `github.com/vitessio/vitess`'s remote. ```shell git fetch origin ``` Creation of the Release Pull Request. > This step will create the Release Pull Request that will then be reviewed ahead of the release day. > The merge commit of that Pull Request will be used during the release day to tag the release. Run the `create_release` script using the Makefile: Release Candidate: ```shell make BASEBRANCH="release-15.0" BASEREMOTE="origin" RELEASEVERSION="15.0.0-rc1" VTOPVERSION="2.8.0-rc1" create_release ``` General Availability: ```shell make BASEBRANCH="release-15.0" BASEREMOTE="origin" RELEASEVERSION="15.0.0"

create_release ``` The script will prompt you `Pausing so release notes can be added. Press enter to continue`. We are now going to generate the release notes, continue to the next sub-step. Run the following command to generate the release notes. Note that you can omit the `--summary` flag if there are no summary. ```shell go run ./go/tools/release-notes --version "v15.0.0" --summary "./changelog/15.0/15.0.0/summary.md" ``` > Make sure to also run `go run ./go/tools/releases/releases.go` to update the `./changelog` directory. > Important note: The release note generation fetches a lot of data from the GitHub API. You might reach the API request limit. In which case you should use the `--threads=` flag and set an integer value lower than 10 (the default). This command will generate the release notes by looking at all the commits between the tag `v14.0.3` and the reference `HEAD`. It will also use the file located in `./changelog/15.0/15.0.0/summary.md` to prefix the release notes with a text that the maintainers wrote before the release. Please verify the generated release notes to make sure it is well-formatted and all the bookmarks are generated properly. Follow the instruction prompted by the `create_release` Makefile command's output in order to push the newly created branch and create the Release Pull Request on GitHub. If we are doing an RC release it means we created a new branch from `main`. We need to update `main` with the next SNAPSHOT version. If `main` was on `15.0.0-SNAPSHOT`, we need to update it to `16.0.0-SNAPSHOT`. A simple find and replace in the IDE is sufficient, there only a handful of files that must be changed: `version.go` and several java files. -- This section is divided into two parts: . This step implies that you have created a beforehand and that it has been reviewed. The merge commit of this Release Pull Request will be used to tag the release. In this example our current version is `v14.0.3` and we release the version `v15.0.0`. Alongside Vitess' release, we also release a new version of the operator. Since we are releasing a release candidate here, the new version of the operator will also be a release candidate. In this example, the new operator version is `2.8.0`. It is important to note that before the RC, there is a code freeze during which we create the release branch. The release branch in this example is `release-15.0`. The example also assumes that `origin` is the `vitessio/vitess` remote. Fetch `github.com/vitessio/vitess`'s remote. ```shell git fetch origin ``` Checkout to the merge commit of the Release Pull Request. Tag the release and push the tags ```shell git tag v15.0.0 && git tag v0.15.0 && git push origin v15.0.0 && git push origin v0.15.0 ``` Create a Pull Request against the `main` branch with the release notes found in `./changelog/15.0/15.0.0/1500_*.md`. Run the back to dev mode tool. ```shell make BASEBRANCH="release-15.0" BASEREMOTE="origin" RELEASEVERSION="15.0.0-rc1" DEVVERSION="15.0.0-SNAPSHOT" backtodev_mode ``` > You will then need to follow the instructions given by the output of the backtodev_mode Makefile command. You will need to push the newly created branch and open a Pull Request. Release the tag on GitHub UI as explained in the following section. In the below steps, we use `v8.0.0` and `v9.0.0` as an example. On Vitess' GitHub repository main page, click on Code -> . On the Releases page, click on `Draft a new release`. When drafting a new release, we are asked to choose the release's tag and branch. We format the tag this way:

We append `-rcN` to the tag name for release candidates, with `N` being the increment of the release candidate. Copy/paste the previously built Release Notes into the description of the release. If this is a pre-release (`rc`) select the `pre-release` checkbox. And finally, click on `Publish release`. -- In this example we are going to do a code freeze on the `release-15.0` branch. If we are doing a release candidate, there won't be a branch yet, hence we need to create it. ``` git fetch --all git checkout -b release-15.0 origin/main ``` Important: after creating the new branch `release-15.0`, we need to create new branch protection rules on the GitHub UI. The rules can be copied from the rules that are on the `main` branch. The new branch will be based on `origin/main`, here `origin` points to `vitessio/vitess`. If we are not doing a release candidate, then the branch already exists and we can checkout on it. Now, if we are doing a GA release, let's update the branch: ``` git pull origin release-15.0 ``` Finally, let's run the code freeze script: ``` ./tools/code_freeze.sh freeze release-15.0 ``` The script will prompt the command that will allow you to push the code freeze change. Once pushed, open a PR that will be merged on `release-15.0`. Remember, you should also disable the Launchable integration from the newly created release branch. -- Warning: It is not advised to merge a PR during code-freeze. If it is deemed absolutely necessary, then the following steps can be followed. The PR that needs to be merged will be failing on the `Code Freeze` CI. To merge this PR, we'll have to mark this CI action as not required. You will need administrator privileges on the vitess repository to be able to make this change. Go to the GitHub repository and click on `Settings`. Under the `Code and automation` section, select `Branches`. Find the branch that you want to merge the PR against and then select `Edit`. Scroll down to find the list of required checks. Within this list find `Code Freeze` and click on the cross next to it to remove it from this list. Save your changes on the bottom of the page. Refresh the page of the PR, and you should be able to merge it. After merging the PR, you need to do 2 more things - Add `Code Freeze` back as a required check. Check if the release PR has any merge conflicts. If it does, fix them and push. -- Warning: This section's steps need to be executed only when releasing a new major version of Vitess, or if the Java packages changed from one minor/patch version to another. For this example, we assume we juste released `v12.0.0`. Checkout to the release commit. ```shell git checkout v12.0.0 ``` Run `gpg-agent` to avoid that Maven will constantly prompt you for the password of your private key. Note that this can print error messages that can be ignored on Mac. ```bash eval $(gpg-agent --daemon --no-grab --write-env-file $HOME/.gpg-agent-info) export GPG_TTY=$(tty) export GPGAGENTINFO ``` Export following to avoid any version conflicts ```bash export MAVEN_OPTS="--add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.text=ALL-UNNAMED --add-opens=java.desktop/java.awt.font=ALL-UNNAMED" ``` Deploy (upload) the Java code to the oss.sonatype.org repository: > Warning: After the deployment, the Java packages will be automatically released. Once released, you cannot delete them. The only option is to upload a newer version (e.g. increment the patch level).</p> ```bash cd ./java/ mvn clean deploy -P release -DskipTests cd .. ``` It will take some time for artifacts to appear on