HHostingByteSoftware
Ctrl K
ComunidadGuías…

RELEASE.md

Rama main · réplica de lectura del repositorio original.

Archivo original ↗Preguntar a KiBot
# Release process for Core

## Minor Releases

### Release Candidates Process

- If this is the first release candidate for a minor version, create a new branch for the minor
  release version. So, if releasing `3.5.0-0.rc.1`, create the `3.5` branch. This can be done
  manually in Github from the [branches][gh-branches] page, or from the command line:
  ```sh
  git checkout main   # new minor release branch should be off of main
  git pull            # make sure `main` is up-to-date
  git checkout -b 3.5 # create the new branch
  git push            # push the new branch up to the remote
  ```
  For subsequent release candidates (e.g., `3.5.0-0.rc.2`), skip this step as the branch already
  exists.

  [gh-branches]: https://github.com/influxdata/influxdb/branches

- Create a new branch that will be used to update the version in `Cargo.toml`:
  ```sh
  git checkout -b chore/3.5/three-five-zero-rc1
  ```

- Update the `version` in `Cargo.toml` by removing the `-nightly` and adding the RC suffix, to
  change it from `3.5.0-nightly` to `3.5.0-0.rc.1`.

- Commit those changes, push, and open a PR from `chore/3.5/three-five-zero-rc1` into `3.5`

- Once that PR is merged into the `3.5` branch on the remote, jump back to the `3.5` branch locally
  to `git pull` and tag/push to trigger the release commit:
  ```
  git tag -a 'v3.5.0-0.rc.1' -m '3.5.0-0.rc.1 release'
  git push origin v3.5.0-0.rc.1
  ```
  For more about proper tag naming conventions, see [Commit Tagging](#commit-tagging).

- This should run the full build and publish the packages. Once the build is finished, you can run a
  quick test with `curl` (replacing `3.5.0-0.rc.1` with your tag name without the leading `v`):
  ```
  curl -LO https://dl.influxdata.com/influxdb/releases/influxdb3-core-3.5.0-0.rc.1_linux_amd64.tar.gz
  ```

- _Note: release candidates do not require updates to the install script, Docker image
  repository, or `apt`/`yum` repositories._

### Official Release Process

- The minor version branch (e.g., `3.5`) should already exist from the release candidate process.
  If not, create it now:
  ```sh
  git checkout main   # new minor release branch should be off of main
  git pull            # make sure `main` is up-to-date
  git checkout -b 3.5 # create the new branch
  git push            # push the new branch up to the remote
  ```

- Create a new branch that will be used to update the version in `Cargo.toml`:
  ```sh
  git checkout -b chore/3.5/three-five-zero
  ```

- Update the `version` in `Cargo.toml` by removing the `-nightly` (or RC suffix if coming from a
  release candidate), to change it to `3.5.0`.

- Commit those changes, push, and open a PR from `chore/3.5/three-five-zero` into `3.5`

- Once that PR is merged into the `3.5` branch on the remote, jump back to the `3.5` branch locally
  to `git pull` and tag/push to trigger the release commit:
  ```
  git tag -a 'v3.5.0' -m '3.5.0 release'
  git push origin v3.5.0
  ```
  For more about proper tag naming conventions, see [Commit Tagging](#commit-tagging).

- This should run the full build and publish the packages. Once the build is finished, you can run a
  quick test with `curl` (replacing `3.5.0` with your tag name without the leading `v`):
  ```
  curl -LO https://dl.influxdata.com/influxdb/releases/influxdb3-core-3.5.0_linux_amd64.tar.gz
  ```

- When satisfied, update `install_influxdb.sh` in
  [influxdata/influxdb-install](https://github.com/influxdata/influxdb-install) to use the new
  version for `INFLUXDB_OSS_VERSION`.

- Once the above is complete, the official Docker image repository needs to be updated. See
  [Official Docker Image Repository](#official-docker-image-repository) for the steps required to
  do so.

- Lastly, `apt` and `yum` repositories need to be updated. This can be done with a change to the
  respective files for `core`/`enterprise` in the private `repos` repository (see [example][repos-commit]).

- After completing the release of `3.5.0`, the version in `Cargo.toml` needs to be updated on the
  `main` branch. Open a branch/PR into the `main` branch that updates the `version` in the
  `Cargo.toml` file from `3.5.0-nightly` to `3.6.0-nightly` (or whatever the subsequent minor
  version is).

### Note on updating Docker Image Repository for Minor releases

For the time being, we are only supporting the most recent released version of InfluxDB 3 Core/Enterprise.
Therefore, when updating the official docker images repository, you do not need to preserve the tags
for the previous version. You can see an example of the [commit][3-1-docker-commit] used when
we released `3.1`.

[3-1-docker-commit]: https://github.com/docker-library/official-images/pull/19123/commits/0bcd57c914f0639c7c07b2dc018469794ac5d367

## Point Releases

- _Note: ideally, any necessary changes will have already have been cherry-picked to the base version
  branch, but it is worth taking a look through the commit history to check for anything that may
  have been missed._

- Checkout the base version branch for the point release. So, if releasing `3.0.2`, checkout `3.0`
  and list out commits to see which was the latest tagged release commit:
  ```
  git checkout 3.0
  git log --oneline --graph
  ```
  There should be a tagged commit from the previous release, in this case `(tag: v3.0.1, ...)`:
  ```
  * d7c071e0c4 (tag: v3.0.1, origin/3.0) chore: version bump for 3.0.1 (#26282)
  * e4cfbf71f7 (origin/pd/three-dot-oh-one) chore: back-port catalog limit refactor from enterprise (#26278)
  ```
  Take note of the commit immediately before it (`e4cfbf71f7` here), as the tagged commit (`d7c071e0c4` here)
  will not appear on the `main` branch.

- Open a branch off of the `3.0` branch before proceeding, we will cherry pick the commits for this
  release onto the new branch:
  ```
  git checkout -b chore/3.0/my-branch-name
  ```

- You need to cherry pick commits from the `main` branch that will go into the `3.0.2` point release,
  so you can list out the most recent commits on the `main` branch to determine those:
  ```
  git log --oneline --graph main
  ```
  Will output:
  ```
  * d30f26618c fix: distinct cache counting bug (#26332)
  * 0f52ebb90d fix: group by tag columns with escape quotes (#26326)
  * b41a2d9bc3 feat: expose `--format json` for token creation cmd (#26286)
  * 2ceed952b8 docs: clarify default maxes for distinct cache (#26281)
  * e4cfbf71f7 (origin/pd/three-dot-oh-one) chore: back-port catalog limit refactor from enterprise (#26278)
  ```
  For any commits newer than the one previously noted (`e4cfbf71f7`), you will want to cherry pick
  them onto the `3.0/my-branch-name` branch in the order they were originally applied:
  ```
  git cherry-pick 2ceed952b8
  git cherry-pick b41a2d9bc3
  git cherry-pick 0f52ebb90d
  git cherry-pick d30f26618c
  ```
  Typically, we focus on `fix` commits, as any other commits will go out on the next minor release,
  but use your discretion about what should be cherry-picked from `main` for the release you are
  doing.

- Once all necessary commits have been `git cherry-pick`'d, push them up to the remote:
  ```
  git push
  ```
  Open a PR from `3.0/my-branch-name` into `3.0` (not `main`) so the changes can be reviewed by
  another developer.

- Once that PR is merged, the version needs to be bumped on the `3.0` branch for the new release, so
  start a new branch:
  ```
  git checkout -b chore/3.0/three-zero-two
  ```
  On this branch, update the `version` in the `Cargo.toml` file to use the desired release version
  in the `[workspace.package]` section.

- Commit and open a PR with the version change _into the `3.0` branch_ (not `main`).

- Once the PR to update the version is merged into the `3.0` branch on the remote, jump back to the
  `3.0` branch locally to `git pull` and tag/push the release commit:
  ```
  git tag -a 'v3.0.2' -m '3.0.2 release'
  git push origin v3.0.2
  ```
  If doing a _release candidate_, or to find more about proper tag naming conventions, see
  [Commit Tagging](#commit-tagging).

- This should run the full build and publish the packages, a quick test will be to run a `curl`
  (replace `3.0.2` with your tag name without the leading `v`)
  ```
  curl -LO https://dl.influxdata.com/influxdb/releases/influxdb3-core-3.0.2_linux_amd64.tar.gz
  ```

- When satisfied, update `install_influxdb.sh` in
  [influxdata/influxdb-install](https://github.com/influxdata/influxdb-install) to use the new
  version for `INFLUXDB_VERSION`

- Once the above is complete, the official Docker image repository needs to be updated. See
  [Official Docker Image Repository](#official-docker-image-repository) for the steps required to
  do so.

- Lastly, `apt` and `yum` repositories need to be updated. This can be done with a change to the
  respective files for `core`/`enterprise` in the private `repos` repository (see [example][repos-commit]).

[repos-commit]: https://github.com/influxdata/repos/pull/179/commits/fa0f8374e52ee86359efd00ce7dcb011d5ebb37a

## Commit Tagging

Annotated tags can be created with `git tag -a <tag_name> -m <description>`, e.g.,

- `git tag -a 'v3.0.0-0.beta.1' -m '3.0.0-beta.1 release'`
- `git tag -a 'v3.0.0-0.beta.2' -m '3.0.0-beta.2 release'`
- `git tag -a 'v3.0.0-0.rc.1' -m '3.0.0-rc.1 release'`
- `git tag -a 'v3.0.0' -m '3.0.0 release'`
- `git tag -a 'v3.0.1' -m '3.0.1 release'`
- `git tag -a 'v3.1.0' -m '3.1.0 release'`

There is a full explanation on what each portion of the tag means, as well as how git tags map to
filenames in `.circleci/packages/config.yaml`. This tag should match the regex as configured in
`release-filter` in `.circleci/config.yml`.

## Official Docker Image Repository

Influx maintains a [repository][influx-docker] of `Dockerfile`s for various projects. The official
Docker image [repository][docker-official] refers to the former.

When a release is complete, the above repositories need to be updated by:

- Updating the `INFLUXDB_VERSION` in the following files in `influxdata-docker` (see [example][ex1]):
  - `influxdb/3.0-core/Dockerfile`
  - `influxdb/3.0-enterprise/Dockerfile`

- Once merged, take the commit SHA from the merge commit, and use it to update the official docker
  image manifest for Influx. In addition to updating the SHA, the image tag with the full version
  numbers need to be updated for `core` and `enterprise` images (see [example][ex2]).

[influx-docker]: https://github.com/influxdata/influxdata-docker
[docker-official]: https://github.com/docker-library/official-images
[ex1]: https://github.com/influxdata/influxdata-docker/commit/a956adaa6d24473d3ea6b9c638d9b4658dfecc44
[ex2]: https://github.com/docker-library/official-images/pull/18972/commits/e543ab7774878d9246ee95c50e8719844b6c6788