зеркало из https://github.com/github/vitess-gh.git
Initial rework of the release instructions
Signed-off-by: Florent Poinsard <florent.poinsard@outlook.fr>
This commit is contained in:
Florent Poinsard
Родитель
a07ffd2b5d
Коммит
06073da1c4
|
|
@ -2,6 +2,17 @@
|
|||
|
||||
This page describes the steps for cutting a new [open source release](https://github.com/vitessio/vitess/releases).
|
||||
|
||||
### Summary
|
||||
|
||||
- [Versioning](#versioning)
|
||||
- [Release Branches](#release-branches)
|
||||
- [Release Tags](#release-tags)
|
||||
- [Docker Images](#docker-images)
|
||||
- [Java Packages](#java-packages)
|
||||
- [Release Cutover](#release-cutover)
|
||||
|
||||
-------
|
||||
|
||||
## Versioning
|
||||
|
||||
Our versioning strategy is based on [VEP5](https://github.com/vitessio/enhancements/blob/main/veps/vep-5.md).
|
||||
|
|
@ -39,6 +50,8 @@ changes) and safe (isolated from active development on `main`).
|
|||
|
||||
Pre-release versions should be labeled with a suffix like `-beta2` or `-rc1`.
|
||||
|
||||
-------
|
||||
|
||||
## Release Branches
|
||||
|
||||
Each major and minor releases (X.Y) should have a [release branch](https://github.com/vitessio/vitess/branches/all?query=release) named
|
||||
|
|
@ -57,6 +70,8 @@ git push upstream release-X.Y
|
|||
The branches are named `release-X.Y` to distinguish them from point-in-time
|
||||
tags, which are named `vX.Y.Z`.
|
||||
|
||||
-------
|
||||
|
||||
## Release Tags
|
||||
|
||||
While the release branch is a moving target, release tags mark point-in-time
|
||||
|
|
@ -64,10 +79,14 @@ snapshots of the repository. Essentially, a tag assigns a human-readable name to
|
|||
a specific Git commit hash. Although it's technically possible to reassign a tag
|
||||
name to a different hash, we must never do this.
|
||||
|
||||
-------
|
||||
|
||||
## Docker Images
|
||||
|
||||
Docker images built automatically on DockerHub and can be found [here](https://hub.docker.com/repository/docker/vitess/lite/).
|
||||
|
||||
-------
|
||||
|
||||
## Java Packages
|
||||
|
||||
We publish binary packages for our [JDBC driver and Java client on Maven Central](https://search.maven.org/#search|ga|1|g:"io.vitess").
|
||||
|
|
@ -95,129 +114,167 @@ Install `gpg-agent` (needed below) e.g. on Ubuntu via: `sudo apt-get install gnu
|
|||
|
||||
Create the `settings.xml` in the `$HOME/.m2/` directory as described in their [instructions](https://central.sonatype.org/pages/apache-maven.html).
|
||||
|
||||
-------
|
||||
|
||||
## Release Cutover
|
||||
|
||||
The release cutover section is divided in 4 steps:
|
||||
### Overview
|
||||
|
||||
1. Pre requisites for either Release or Release Candidate (`rc`).
|
||||
2. Creation of Release or Release Candidate (`rc`) on GitHub.
|
||||
3. Post release steps.
|
||||
4. Java Packages deploy.
|
||||
For each release, it is recommended to create an issue like [this one](https://github.com/vitessio/vitess/issues/10476) to track the current and past progress of a release.
|
||||
It also allows us to document what happened during a release.
|
||||
|
||||
### Pre-Requisites for Release Candidates (`rc`)
|
||||
The release process can be divided in three parts: [**Pre-Release**](#pre-release), [**Release**](#release), [**Post-Release**](#post-release). The three following sections describe each part.
|
||||
|
||||
### Pre-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.
|
||||
- Making sure the people doing the release have access to all the tools and infrastructure needed to do the release.
|
||||
- Preparing and cleaning the release notes summary.
|
||||
- Finishing the blog post, and coordinating with the different organisation on which we want to cross-post. Often with CNCF. This step applies only for GA releases.
|
||||
|
||||
### Release
|
||||
|
||||
During the release day, there are several things to do:
|
||||
|
||||
- Create the Vitess release.
|
||||
- A guide on how to create a Vitess release is available in the [How To Release Vitess](#how-to-release-vitess) section.
|
||||
- Create the corresponding Vitess operator release. _Applies only to versions greater or equal to `v14.0.0`._
|
||||
- Create the Java release. _Applies only to GA releases._
|
||||
- This step is explained in the [Java Packages Deploy & Release](#java-packages-deploy--release) section.
|
||||
- Update the website documentation repository. _Applies only to GA and RC releases._
|
||||
- Publish the blog post on the Vitess website. _Only for GA releases._
|
||||
- Make sure _arewefastyet_ starts benchmarking the new release. This can be done by visiting [this link](https://benchmark.vitess.io/status).
|
||||
- Update the release notes on the release branch and on `main`.
|
||||
|
||||
### Post-Release
|
||||
|
||||
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.
|
||||
|
||||
|
||||
### How To Release Vitess
|
||||
This section is divided in three parts:
|
||||
- How to release an RC: [Pre-Requisites for Release Candidates (`rc`)](#pre-requisites-for-release-candidates-rc).
|
||||
- How to release a GA or Patch release: [Pre-Requisites for Releases](#pre-requisites-for-releases).
|
||||
- Common to both, how to create the release on the GitHub UI: [#Creating Release or Release Candidate on the GitHub UI](#creating-release-or-release-candidate-on-the-github-ui)
|
||||
|
||||
|
||||
#### Pre-Requisites for Release Candidates (`rc`)
|
||||
|
||||
> In this example our current version is `v11` and we release the version `v12.0.0-rc1`.
|
||||
> 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.7.0-rc1`.
|
||||
|
||||
* Announce dates on Vitess slack `#release-planning`.
|
||||
|
||||
* Fetch `github.com/vitessio/vitess`'s remote.
|
||||
1. Fetch `github.com/vitessio/vitess`'s remote.
|
||||
```shell
|
||||
git fetch <vitessio/vitess remote>
|
||||
```
|
||||
|
||||
* Build a Release Notes document using the Makefile:
|
||||
```shell
|
||||
make VERSION="v12.0.0" FROM="<ref/SHA of the latest tag for v11>" TO="<ref/SHA of main>" SUMMARY="./doc/releasenotes/12_0_0_summary.md" release-notes
|
||||
```
|
||||
|
||||
* Check to make sure all labels and categories set for each PR.
|
||||
|
||||
> The Release Notes document can be put aside for now, it will be used when creating the release tag in a future step.
|
||||
|
||||
* Create a new release branch from main.
|
||||
2. Create a new release branch from `main`.
|
||||
```shell
|
||||
git checkout -b release-12.0 upstream/main
|
||||
```
|
||||
|
||||
* Run the release script using the Makefile:
|
||||
```shell
|
||||
make RELEASE_VERSION="12.0.0-rc1" DEV_VERSION="12.0.0-SNAPSHOT" do_release
|
||||
```
|
||||
|
||||
> The script will prompt you `Pausing so relase notes can be added. Press enter to continue`, execute the next step and press enter.
|
||||
|
||||
* Put the Release Notes document in `./doc/releasenotes/12_0_0_release_notes.md`.
|
||||
3. Creation of the release notes and tags.
|
||||
1. Run the release script using the Makefile:
|
||||
```shell
|
||||
make RELEASE_VERSION="12.0.0-rc1" DEV_VERSION="12.0.0-SNAPSHOT" VTOP_VERSION="2.7.0-rc1" do_release
|
||||
```
|
||||
The script will prompt you `Pausing so relase notes can be added. Press enter to continue`. We are now going to generate the release notes, continue to the next sub-step.
|
||||
|
||||
2. Run the following command to generate the release notes:
|
||||
```shell
|
||||
make VERSION="v12.0.0-rc1" FROM="v11.0.0" TO="HEAD" SUMMARY="./doc/releasenotes/12_0_0_summary.md" release-notes
|
||||
```
|
||||
This command will generate the release notes by looking at all the commits between the tag `v11.0.0` and the reference `HEAD`.
|
||||
It will also use the file located in `./doc/releasenotes/12_0_0_summary.md` to prefix the release notes with a text that the maintainers wrote before the release.
|
||||
|
||||
* Push the current dev branch to upstream. No pull request required.
|
||||
```shell
|
||||
git push upstream release-12.0
|
||||
```
|
||||
|
||||
* As prompted in the `do_release` Makefile command's output, push the the `v12.0.0-rc1` tag.
|
||||
|
||||
4. As prompted in the `do_release` Makefile command's output, push the the `v12.0.0-rc1` tag.
|
||||
```shell
|
||||
git push upstream v12.0.0-rc1
|
||||
```
|
||||
|
||||
* Release the tag on GitHub UI as explained in the following section.
|
||||
|
||||
------
|
||||
### Pre-Requisites for Releases
|
||||
5. Push the current dev branch to upstream. No pull request required. **To achieve this action, you need to be able to create new branches on `vitessio/vitess`**.
|
||||
```shell
|
||||
git push upstream release-12.0
|
||||
```
|
||||
|
||||
> In this example our current version is `v11` and we release the version `v12.0.0`.
|
||||
6. Create a Pull Request against the `main` branch with the newly created release notes.
|
||||
|
||||
7. Release the tag on GitHub UI as explained in the following section.
|
||||
|
||||
|
||||
* Announce dates on Vitess slack `#release-planning`.
|
||||
#### Pre-Requisites for Releases
|
||||
|
||||
* Fetch `github.com/vitessio/vitess`'s remote.
|
||||
> In this example our current version is `v11` and we release the version `v12.0.0`. Before releasing `v12.0.0`, usually three weeks before, we released the release candidate for `v12.0.0`.
|
||||
> We are also going to make the latest version of the operator GA. In our example the operator version is `v2.7.0`.
|
||||
|
||||
1. Fetch `github.com/vitessio/vitess`'s remote.
|
||||
```shell
|
||||
git fetch <vitessio/vitess remote>
|
||||
```
|
||||
|
||||
* Build a Release Notes document using the Makefile:
|
||||
2. Create a temporary release branch that will be based on our long-term release branch for `v12.0.0`. In our case, the release branch is `release-12.0`.
|
||||
```shell
|
||||
make VERSION="v12.0.0" FROM="<ref/SHA of the latest tag for v11>" TO="<ref/SHA of main>" SUMMARY="./doc/releasenotes/12_0_0_summary.md" release-notes
|
||||
git checkout -b release-12.0.0 upstream/release-12.0
|
||||
```
|
||||
|
||||
* Check to make sure all labels and categories set for each PR.
|
||||
3. Creation of the release notes and tags.
|
||||
1. Run the release script using the Makefile:
|
||||
```shell
|
||||
make RELEASE_VERSION="12.0.0" GODOC_RELEASE_VERSION="0.12.0" DEV_VERSION="12.0.1-SNAPSHOT" VTOP_VERSION="2.7.0" do_release
|
||||
```
|
||||
The script will prompt you `Pausing so relase notes can be added. Press enter to continue`. We are now going to generate the release notes, continue to the next sub-step.
|
||||
|
||||
> The Release Notes document can be put aside for now, it will be used when creating the release tag in a future step.
|
||||
2. Run the following command to generate the release notes:
|
||||
```shell
|
||||
make VERSION="v12.0.0" FROM="v11.0.0" TO="HEAD" SUMMARY="./doc/releasenotes/12_0_0_summary.md" release-notes
|
||||
```
|
||||
This command will generate the release notes by looking at all the commits between the tag `v11.0.0` and the reference `HEAD`.
|
||||
It will also use the file located in `./doc/releasenotes/12_0_0_summary.md` to prefix the release notes with a text that the maintainers wrote before the release.
|
||||
|
||||
* Make sure to stand in the latest commit of the release branch (`upstream/release-12.0` in our example).
|
||||
Then, checkout to a new branch that will be used to push our release commits.
|
||||
```shell
|
||||
git checkout -b at-release-12.0.0 upstream/release-12.0
|
||||
```
|
||||
|
||||
* Run the release script using the Makefile:
|
||||
```
|
||||
make RELEASE_VERSION="12.0.0" GODOC_RELEASE_VERSION="0.12.0" DEV_VERSION="12.0.1-SNAPSHOT" do_release
|
||||
```
|
||||
|
||||
> The script will prompt you `Pausing so relase notes can be added. Press enter to continue`, execute the next step and press enter.
|
||||
|
||||
* Put the Release Notes document in `./doc/releasenotes/12_0_0_release_notes.md`.
|
||||
|
||||
* Put the output in `./doc/releasenotes/12_0_0_release_notes.md`.
|
||||
|
||||
* Push your current branch and create a pull request against the existing `release-12.0` branch.
|
||||
```shell
|
||||
git push origin at-release-12.0.0
|
||||
```
|
||||
|
||||
* As prompted in the `do_release` Makefile command's output, push the `v12.0.0` and `v0.12.0` tags.
|
||||
4. As prompted in the `do_release` Makefile command's output, push the `v12.0.0` and `v0.12.0` tags.
|
||||
```shell
|
||||
git push upstream v12.0.0 && git push upstream v0.12.0
|
||||
```
|
||||
|
||||
* Release the tag on GitHub UI as explained in the following section.
|
||||
5. Push your current branch and create a pull request against the existing `release-12.0` branch.
|
||||
```shell
|
||||
git push origin release-12.0.0
|
||||
```
|
||||
|
||||
### Creating Release or Release Candidate
|
||||
6. Create a Pull Request against the `main` branch with the newly created release notes.
|
||||
|
||||
7. Release the tag on GitHub UI as explained in the following section.
|
||||
|
||||
|
||||
#### Creating Release or Release Candidate on the GitHub UI
|
||||
|
||||
> In the below steps, we use `v8.0.0` and `v9.0.0` as an example.
|
||||
|
||||
#### 1. Open the releases page
|
||||
##### 1. Open the releases page
|
||||
|
||||
On Vitess' GitHub repository main page, click on Code -> [Releases](https://github.com/vitessio/vitess/releases).
|
||||
|
||||
|
||||
|
||||
#### 2. Draft a new release
|
||||
##### 2. Draft a new release
|
||||
|
||||
On the Releases page, click on `Draft a new release`.
|
||||
|
||||
|
||||
|
||||
#### 3. Tag a new release
|
||||
##### 3. Tag 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: `v9.0.0`. We append `-rcN` to the tag name for release candidates,
|
||||
|
|
@ -225,7 +282,7 @@ with `N` being the increment of the release candidate.
|
|||
|
||||
|
||||
|
||||
#### 4. Add release notes and release
|
||||
##### 4. Add release notes and release
|
||||
|
||||
Copy/paste the previously built Release Notes into the description of the release.
|
||||
|
||||
|
|
@ -235,19 +292,6 @@ And finally, click on `Publish release`.
|
|||
|
||||
|
||||
|
||||
### Post Release Steps
|
||||
* Announce new release in Vitess Slack `#general` channel.
|
||||
* Create a new [PR](https://github.com/vitessio/website/pull/670) for Vitess Blog.
|
||||
* Netlify -> Sites →vitess.io → Deploy 
|
||||
* Coordinate CNCF cross-posting Vitess Blog.
|
||||
* Schedule and publish Tweet on Vitess account.
|
||||
* Run following script to once the `base` Docker image is live.
|
||||
|
||||
```
|
||||
https://github.com/vitessio/vitess/blob/main/docker/release.sh
|
||||
```
|
||||
|
||||
* Deploy and release Java packages by following the `Java Packages Deploy & Release` section below.
|
||||
|
||||
### Java Packages Deploy & Release
|
||||
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче