Support Policy

The Bazel community maintains this repository. Neither Google nor the Bazel teamprovides support for the code. However, this repository is part of the testsuite used to vet new Bazel releases. See theHow to contributepage for information on our development workflow.

Supported rules_python Versions

In general, only the latest version is supported. Backporting changes isdone on a best-effort basis based on severity, risk of regressions, andthe willingness of volunteers.

If you want or need particular functionality backported, then the best wayis to open a PR to demonstrate the feasibility of the backport.

Backports and Patch Releases

Backports and patch releases are provided on a best-effort basis. Only fixes arebackported. Features are not backported.

Backports can be done to older releases, but only if newer releases also havethe fix backported. For example, if the current release is 1.5, in order topatch 1.4, version 1.5 must be patched first.

Backports can be requested bycreating an issue with the patch releasetemplate or by sending a pull request performing the backport.See the dev guide forhow to create a backport PR.

Supported Bazel Versions

The supported Bazel versions are:

  1. The latest rolling release

  2. The active major release.

  3. The major release prior to the active release.

For (2) and (3) above, only the latest minor/patch version of the major releaseis officially supported. Earlier minor/patch versions are supported on abest-effort basis only. We increase the minimum minor/patch version as necessaryto fix bugs or introduce functionality relying on features introduced in laterminor/patch versions.

SeeBazel’s release support matrixfor what versions are the rolling, active, and prior releases.

Supported Python versions

As a general rule, we test all released non-EOL Python versions. Differentinterpreter versions may work but are not guaranteed. We are interested instaying compatible with upcoming unreleased versions, so if you see that thingsstop working, please create tickets or, more preferably, pull requests.

Supported Platforms

We only support the platforms that our continuous integration jobs run on, whichare Linux, Mac, and Windows.

In order to better describe different support levels, the following acts as a roughguideline for different platform tiers:

  • Tier 0 - The platforms that our CI runs on:linux_x86_64,osx_arm64,RBElinux_x86_64.

  • Tier 1 - The platforms that are similar enough to what the CI runs on:linux_aarch64,osx_x86_64.What is more,windows_x86_64 is in this list, as we run tests in CI, butdeveloping for Windows is more challenging, and features may come later tothis platform.

  • Tier 2 - The rest of the platforms that may have a varying level of support, e.g.,linux_s390x,linux_ppc64le,windows_arm64.

Note

Code to support Tier 2 platforms is allowed, but regressions will be fixed on abest-effort basis, so feel free to contribute by creating PRs.

If you would like to provide/sponsor CI setup for a platform that is not Tier 0,please create a ticket or contact the maintainers on Slack.

Compatibility Policy

We generally follow theBazel RuleCompatibility guidelines, whichprovides a path from an arbitrary release to the latest release in anincremental fashion.

Breaking changes are allowed, but follow a process to introduce them overa series of releases to so users can still incrementally upgrade. See theBreaking Changes doc for the process.

Experimental Features

An experimental feature is functionality that may not be ready for generaluse and may change quickly and/or significantly. Such features are denoted intheir name or API docs as “experimental”. They may have breaking changes made atany time.

If you like or use an experimental feature, then file issues to request it betaken out of experimental. Often times these features are experimental becausewe need feedback or experience to verify they are working, useful, and worth theeffort of supporting.