1# Support Policy 2 3The Bazel community maintains this repository. Neither Google nor the Bazel team 4provides support for the code. However, this repository is part of the test 5suite used to vet new Bazel releases. See the <project:#contributing> 6page for information on our development workflow. 7 8## Supported rules_python Versions 9 10In general, only the latest version is supported. Backporting changes is 11done on a best effort basis based on severity, risk of regressions, and 12the willingness of volunteers. 13 14If you want or need particular functionality backported, then the best way 15is to open a PR to demonstrate the feasibility of the backport. 16 17## Supported Bazel Versions 18 19The supported Bazel versions are: 20 211. The latest rolling release 222. The active major release. 233. The major release prior to the active release. 24 25For (2) and (3) above, only the latest minor/patch version of the major release 26is officially supported. Earlier minor/patch versions are supported on a 27best-effort basis only. We increase the minimum minor/patch version as necessary 28to fix bugs or introduce functionality relying on features introduced in later 29minor/patch versions. 30 31See [Bazel's release support matrix](https://bazel.build/release#support-matrix) 32for what versions are the rolling, active, and prior releases. 33 34## Supported Platforms 35 36We only support the platforms that our continuous integration jobs run, which 37is Linux, Mac, and Windows. Code to support other platforms is allowed, but 38can only be on a best-effort basis. 39 40## Compatibility Policy 41 42We generally follow the [Bazel Rule 43Compatibility](https://bazel.build/release/rule-compatibility) guidelines, which 44provides a path from an arbitrary release to the latest release in an 45incremental fashion. 46 47Breaking changes are allowed, but follow a process to introduce them over 48a series of releases to so users can still incrementally upgrade. See the 49[Breaking Changes](#breaking-changes) doc for the process. 50 51 52## Experimental Features 53 54An experimental features is functionality that may not be ready for general 55use and may change quickly and/or significantly. Such features are denoted in 56their name or API docs as "experimental". They may have breaking changes made at 57any time. 58 59If you like or use an experimental feature, then file issues to request it be 60taken out of experimental. Often times these features are experimental because 61we need feedback or experience to verify they are working, useful, and worth the 62effort of supporting. 63