site/en/release/index.md - bazel - Git at Google

 Project: /_project.yaml
 Book: /_book.yaml

 # Release Model

 {% dynamic setvar source_file "site/en/release/index.md" %}
 {% include "_buttons.html" %}

 As announced in [the original blog
 post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.

 ## Support matrix {:#support-matrix}

 | LTS release | Support stage | Latest version | End of support |
 | ----------- | ------------- | -------------- | -------------- |
 | Bazel 9 | Rolling| [Check rolling release page](/release/rolling) | N/A |
 | Bazel 8 | Active| [8.3.1](https://github.com/bazelbuild/bazel/releases/tag/8.3.1){: .external} | December 2027 |
 | Bazel 7 | Maintenance| [7.6.1](https://github.com/bazelbuild/bazel/releases/tag/7.6.1){: .external} | Dec 2026 |
 | Bazel 6 | Maintenance | [6.5.0](https://github.com/bazelbuild/bazel/releases/tag/6.5.0){: .external} | Dec 2025 |
 | Bazel 5 | Deprecated | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1){: .external} | Jan 2025 |
 | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4){: .external} | Jan 2024 |

 All Bazel LTS releases can be found on the [release
 page](https://github.com/bazelbuild/bazel/releases){: .external} on GitHub.

 Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
 want to keep up with the latest changes at HEAD.

 ## Release versioning {:#bazel-versioning}

 Bazel uses a _major.minor.patch_ [Semantic
 Versioning](https://semver.org/){: .external} scheme.

 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
 *   A _minor release_ contains backward-compatible bug fixes and features
     back-ported from the main branch.
 *   A _patch release_ contains critical bug fixes.

 Additionally, pre-release versions are indicated by appending a hyphen and a
 date suffix to the next major version number.

 For example, a new release of each type would result in these version numbers:

 *   Major: 6.0.0
 *   Minor: 6.1.0
 *   Patch: 6.1.2
 *   Pre-release: 7.0.0-pre.20230502.1

 ## Support stages {:#support-stages}

 For each major Bazel version, there are four support stages:

 *   **Rolling**: This major version is still in pre-release, the Bazel team
     publishes rolling releases from HEAD.
 *   **Active**: This major version is the current active LTS release. The Bazel
   team backports important features and bug fixes into its minor releases.
 *   **Maintenance**: This major version is an old LTS release in maintenance
     mode. The Bazel team only promises to backport critical bug fixes for
     security issues and OS-compatibility issues into this LTS release.
 *   **Deprecated**: The Bazel team no longer provides support for this major
     version, all users should migrate to newer Bazel LTS releases.

 ## Release cadence {:#release-cadence}

 Bazel regularly publish releases for two release tracks.

 ### Rolling releases {:#rolling-releases}

 *   Rolling releases are coordinated with Google Blaze release and are released
   from HEAD around every two weeks. It is a preview of the next Bazel LTS
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
     should follow our [backward compatibility
     policy](/release/backward-compatibility).

 ### LTS releases {:#lts-releases}

 *   _Major release_: A new LTS release is expected to be cut from HEAD roughly
     every
     12 months. Once a new LTS release is out, it immediately enters the Active
     stage, and the previous LTS release enters the Maintenance stage.
 *   _Minor release_: New minor verions on the Active LTS track are expected to
     be released once every 2 months.
 *   _Patch release_: New patch versions for LTS releases in Active and
     Maintenance stages are expected to be released on demand for critical bug
     fixes.
 *   A Bazel LTS release enters the Deprecated stage after being in the
     Maintenance stage for 2 years.

 For planned releases, please check our [release
 issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease){: .external}
 on Github.

 ## Release procedure & policies {:#release-procedure-policies}

 For rolling releases, the process is straightforward: about every two weeks, a
 new release is created, aligning with the same baseline as the Google internal
 Blaze release. Due to the rapid release schedule, we don't backport any changes
 to rolling releases.

 For LTS releases, the procedure and policies below are followed:

 1.  Determine a baseline commit for the release.
     *   For a new major LTS release, the baseline commit is the HEAD of the main
         branch.
     *   For a minor or patch release, the baseline commit is the HEAD of the
         current latest version of the same LTS release.
 1.  Create a release branch in the name of `release-<version>` from the baseline
     commit.
 1.  Backport changes via PRs to the release branch.
     *   The community can suggest certain commits to be back-ported by replying
    "`@bazel-io flag`" on relevant GitHub issues or PRs to mark them as potential
         release blockers, the Bazel team triages them and decide whether to
         back-port the commits.
     *   Only backward-compatible commits on the main branch can be back-ported,
    additional minor changes to resolve merge conflicts are acceptable.
 1.  Backport changes using Cherry-Pick Request Issue for Bazel maintainers.
     *   Bazel maintainers can request to cherry-pick specific commit(s)
         to a release branch. This process is initiated by creating a
         cherry-pick request on GitHub. Here's how to do it.
         1.  Open the [cherry-pick request](https://github.com/bazelbuild/bazel/issues/new?assignees=&labels=&projects=&template=cherry_pick_request.yml){: .external}
         2.  Fill in the request details
             *   Title: Provide a concise and descriptive title for the request.
             *   Commit ID(s): Enter the ID(s) of the commit(s) you want to
                 cherry-pick. If there are multiple commits, then separate
                 them with commas.
             *   Category: Specify the category of the request.
             *   Reviewer(s): For multiple reviewers, separate their GitHub
                 ID's with commas.
         3.  Set the milestone
             *   Find the "Milestone" section and click the setting.
             *   Select the appropriate X.Y.Z release blockers. This action
                 triggers the cherry-pick bot to process your request
                 for the "release-X.Y.Z" branch.
         4.  Submit the Issue
             *   Once all details are filled in and the miestone is set,
                 submit the issue.

     *   The cherry-pick bot will process the request and notify
         if the commit(s) are eligible for cherry-picking. If
         the commits are cherry-pickable, which means there's no
         merge conflict while cherry-picking the commit, then
         the bot will create a new pull request. When the pull
         request is approved by a member of the Bazel team, the
         commits are cherry-picked and merged to the release branch.
         For a visual example of a completed cherry-pick request,
         refer to this
         [example](https://github.com/bazelbuild/bazel/issues/20230){: .external}
         .

 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel){: .external} and
         [downstream test pipeline]
         (https://buildkite.com/bazel/bazel-at-head-plus-downstream){: .external}
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
     release blockers are resolved.
     *   The release candidate is announced on
         [bazel-discuss](https://groups.google.com/g/bazel-discuss){: .external},
         the Bazel team monitors community bug reports for the candidate.
     *   If new release blockers are identified, go back to the last step and
         create a new release candidate after resolving all the issues.
     *   New features are not allowed to be added to the release branch after the
         first release candidate is created; cherry-picks are limited to critical
         fixes only. If a cherry-pick is needed, the requester must answer the
         following questions: Why is this change critical, and what benefits does
         it provide? What is the likelihood of this change introducing a
         regression?
 1.  Push the release candidate as the official release if no further release
     blockers are found
     *   For patch releases, push the release at least two business days after
         the last release candidate is out.
     *   For major and minor releases, push the release two business days after
         the last release candidate is out, but not earlier than one week after
         the first release candidate is out.
     *   The release is only pushed on a day where the next day is a business
         day.
     *   The release is announced on
         [bazel-discuss](https://groups.google.com/g/bazel-discuss){: .external},
         the Bazel team monitors and addresses community bug reports for the new
      release.

 ## Report regressions {:#report-regressions}

 If a user finds a regression in a new Bazel release, release candidate or even
 Bazel at HEAD, please file a bug on
 [GitHub](https://github.com/bazelbuild/bazel/issues){: .external}. You can use
 Bazelisk to bisect the culprit commit and include this information in the bug
 report.

 For example, if your build succeeds with Bazel 6.1.0 but fails with the second
 release candidate of 6.2.0, you can do bisect via

 ```bash
 bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar
 ```

 You can set `BAZELISK_SHUTDOWN` or `BAZELISK_CLEAN` environment variable to run
 corresponding bazel commands to reset the build state if it's needed to
 reproduce the issue. For more details, check out documentation about Bazelisk
 [bisect feature] (https://github.com/bazelbuild/bazelisk#--bisect){: .external}.

 Remember to upgrade Bazelisk to the latest version to use the bisect
 feature.

 ## Rule compatibility {:#rule-compatibility}

 If you are a rule authors and want to maintain compatibility with different
 Bazel versions, please check out the [Rule
 Compatibility](/release/rule-compatibility) page.
	Project: /_project.yaml
	Book: /_book.yaml

	# Release Model

	{% dynamic setvar source_file "site/en/release/index.md" %}
	{% include "_buttons.html" %}

	As announced in [the original blog
	post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
	4.0 and higher versions provides support for two release tracks: rolling
	releases and long term support (LTS) releases. This page covers the latest
	information about Bazel's release model.

	## Support matrix {:#support-matrix}

	\| LTS release \| Support stage \| Latest version \| End of support \|
	\| ----------- \| ------------- \| -------------- \| -------------- \|
	\| Bazel 9 \| Rolling\| [Check rolling release page](/release/rolling) \| N/A \|
	\| Bazel 8 \| Active\| [8.3.1](https://github.com/bazelbuild/bazel/releases/tag/8.3.1){: .external} \| December 2027 \|
	\| Bazel 7 \| Maintenance\| [7.6.1](https://github.com/bazelbuild/bazel/releases/tag/7.6.1){: .external} \| Dec 2026 \|
	\| Bazel 6 \| Maintenance \| [6.5.0](https://github.com/bazelbuild/bazel/releases/tag/6.5.0){: .external} \| Dec 2025 \|
	\| Bazel 5 \| Deprecated \| [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1){: .external} \| Jan 2025 \|
	\| Bazel 4 \| Deprecated \| [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4){: .external} \| Jan 2024 \|

	All Bazel LTS releases can be found on the [release
	page](https://github.com/bazelbuild/bazel/releases){: .external} on GitHub.

	Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
	recommended to upgrade to the latest LTS release or use rolling releases if you
	want to keep up with the latest changes at HEAD.

	## Release versioning {:#bazel-versioning}

	Bazel uses a _major.minor.patch_ [Semantic
	Versioning](https://semver.org/){: .external} scheme.

	* A _major release_ contains features that are not backward compatible with
	the previous release. Each major Bazel version is an LTS release.
	* A _minor release_ contains backward-compatible bug fixes and features
	back-ported from the main branch.
	* A _patch release_ contains critical bug fixes.

	Additionally, pre-release versions are indicated by appending a hyphen and a
	date suffix to the next major version number.

	For example, a new release of each type would result in these version numbers:

	* Major: 6.0.0
	* Minor: 6.1.0
	* Patch: 6.1.2
	* Pre-release: 7.0.0-pre.20230502.1

	## Support stages {:#support-stages}

	For each major Bazel version, there are four support stages:

	* Rolling: This major version is still in pre-release, the Bazel team
	publishes rolling releases from HEAD.
	* Active: This major version is the current active LTS release. The Bazel
	team backports important features and bug fixes into its minor releases.
	* Maintenance: This major version is an old LTS release in maintenance
	mode. The Bazel team only promises to backport critical bug fixes for
	security issues and OS-compatibility issues into this LTS release.
	* Deprecated: The Bazel team no longer provides support for this major
	version, all users should migrate to newer Bazel LTS releases.

	## Release cadence {:#release-cadence}

	Bazel regularly publish releases for two release tracks.

	### Rolling releases {:#rolling-releases}

	* Rolling releases are coordinated with Google Blaze release and are released
	from HEAD around every two weeks. It is a preview of the next Bazel LTS
	release.
	* Rolling releases can ship incompatible changes. Incompatible flags are
	recommended for major breaking changes, rolling out incompatible changes
	should follow our [backward compatibility
	policy](/release/backward-compatibility).

	### LTS releases {:#lts-releases}

	* _Major release_: A new LTS release is expected to be cut from HEAD roughly
	every
	12 months. Once a new LTS release is out, it immediately enters the Active
	stage, and the previous LTS release enters the Maintenance stage.
	* _Minor release_: New minor verions on the Active LTS track are expected to
	be released once every 2 months.
	* _Patch release_: New patch versions for LTS releases in Active and
	Maintenance stages are expected to be released on demand for critical bug
	fixes.
	* A Bazel LTS release enters the Deprecated stage after being in the
	Maintenance stage for 2 years.

	For planned releases, please check our [release
	issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease){: .external}
	on Github.

	## Release procedure & policies {:#release-procedure-policies}

	For rolling releases, the process is straightforward: about every two weeks, a
	new release is created, aligning with the same baseline as the Google internal
	Blaze release. Due to the rapid release schedule, we don't backport any changes
	to rolling releases.

	For LTS releases, the procedure and policies below are followed:

	1. Determine a baseline commit for the release.
	* For a new major LTS release, the baseline commit is the HEAD of the main
	branch.
	* For a minor or patch release, the baseline commit is the HEAD of the
	current latest version of the same LTS release.
	1. Create a release branch in the name of `release-<version>` from the baseline
	commit.
	1. Backport changes via PRs to the release branch.
	* The community can suggest certain commits to be back-ported by replying
	"`@bazel-io flag`" on relevant GitHub issues or PRs to mark them as potential
	release blockers, the Bazel team triages them and decide whether to
	back-port the commits.
	* Only backward-compatible commits on the main branch can be back-ported,
	additional minor changes to resolve merge conflicts are acceptable.
	1. Backport changes using Cherry-Pick Request Issue for Bazel maintainers.
	* Bazel maintainers can request to cherry-pick specific commit(s)
	to a release branch. This process is initiated by creating a
	cherry-pick request on GitHub. Here's how to do it.
	1. Open the [cherry-pick request](https://github.com/bazelbuild/bazel/issues/new?assignees=&labels=&projects=&template=cherry_pick_request.yml){: .external}
	2. Fill in the request details
	* Title: Provide a concise and descriptive title for the request.
	* Commit ID(s): Enter the ID(s) of the commit(s) you want to
	cherry-pick. If there are multiple commits, then separate
	them with commas.
	* Category: Specify the category of the request.
	* Reviewer(s): For multiple reviewers, separate their GitHub
	ID's with commas.
	3. Set the milestone
	* Find the "Milestone" section and click the setting.
	* Select the appropriate X.Y.Z release blockers. This action
	triggers the cherry-pick bot to process your request
	for the "release-X.Y.Z" branch.
	4. Submit the Issue
	* Once all details are filled in and the miestone is set,
	submit the issue.

	* The cherry-pick bot will process the request and notify
	if the commit(s) are eligible for cherry-picking. If
	the commits are cherry-pickable, which means there's no
	merge conflict while cherry-picking the commit, then
	the bot will create a new pull request. When the pull
	request is approved by a member of the Bazel team, the
	commits are cherry-picked and merged to the release branch.
	For a visual example of a completed cherry-pick request,
	refer to this
	[example](https://github.com/bazelbuild/bazel/issues/20230){: .external}
	.

	1. Identify release blockers and fix issues found on the release branch.
	* The release branch is tested with the same test suite in
	[postsubmit](https://buildkite.com/bazel/bazel-bazel){: .external} and
	[downstream test pipeline]
	(https://buildkite.com/bazel/bazel-at-head-plus-downstream){: .external}
	on Bazel CI. The Bazel team monitors testing results of the release
	branch and fixes any regressions found.
	1. Create a new release candidate from the release branch when all known
	release blockers are resolved.
	* The release candidate is announced on
	[bazel-discuss](https://groups.google.com/g/bazel-discuss){: .external},
	the Bazel team monitors community bug reports for the candidate.
	* If new release blockers are identified, go back to the last step and
	create a new release candidate after resolving all the issues.
	* New features are not allowed to be added to the release branch after the
	first release candidate is created; cherry-picks are limited to critical
	fixes only. If a cherry-pick is needed, the requester must answer the
	following questions: Why is this change critical, and what benefits does
	it provide? What is the likelihood of this change introducing a
	regression?
	1. Push the release candidate as the official release if no further release
	blockers are found
	* For patch releases, push the release at least two business days after
	the last release candidate is out.
	* For major and minor releases, push the release two business days after
	the last release candidate is out, but not earlier than one week after
	the first release candidate is out.
	* The release is only pushed on a day where the next day is a business
	day.
	* The release is announced on
	[bazel-discuss](https://groups.google.com/g/bazel-discuss){: .external},
	the Bazel team monitors and addresses community bug reports for the new
	release.

	## Report regressions {:#report-regressions}

	If a user finds a regression in a new Bazel release, release candidate or even
	Bazel at HEAD, please file a bug on
	[GitHub](https://github.com/bazelbuild/bazel/issues){: .external}. You can use
	Bazelisk to bisect the culprit commit and include this information in the bug
	report.

	For example, if your build succeeds with Bazel 6.1.0 but fails with the second
	release candidate of 6.2.0, you can do bisect via

	```bash
	bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar
	```

	You can set `BAZELISK_SHUTDOWN` or `BAZELISK_CLEAN` environment variable to run
	corresponding bazel commands to reset the build state if it's needed to
	reproduce the issue. For more details, check out documentation about Bazelisk
	[bisect feature] (https://github.com/bazelbuild/bazelisk#--bisect){: .external}.

	Remember to upgrade Bazelisk to the latest version to use the bisect
	feature.

	## Rule compatibility {:#rule-compatibility}

	If you are a rule authors and want to maintain compatibility with different
	Bazel versions, please check out the [Rule
	Compatibility](/release/rule-compatibility) page.