| ranjanih | f1dca86 | 2020-12-09 15:11:06 -0800 | [diff] [blame] | 1 | --- |
| 2 | layout: documentation |
| 3 | title: Release versioning |
| daroberts | 223aebd | 2021-02-18 17:53:30 -0800 | [diff] [blame] | 4 | category: getting-started |
| ranjanih | f1dca86 | 2020-12-09 15:11:06 -0800 | [diff] [blame] | 5 | --- |
| 6 | |
| Googler | 9e7ae8d | 2021-01-08 19:01:23 -0800 | [diff] [blame] | 7 | # Release Versioning |
| ranjanih | f1dca86 | 2020-12-09 15:11:06 -0800 | [diff] [blame] | 8 | |
| 9 | Bazel 4.0 and higher provides support for two release tracks: long term support |
| 10 | (LTS) releases and rolling releases. This page covers versioning in Bazel, the |
| 11 | types of releases, and the benefits of those releases for Bazel users and |
| 12 | contributors. |
| 13 | |
| 14 | ## Understanding versioning on Bazel |
| 15 | |
| 16 | Bazel uses a _major.minor.patch_ semantic versioning scheme. |
| 17 | |
| 18 | * A _major release_ contains features that are not backward compatible with the |
| 19 | previous release. |
| 20 | * A _minor release_ contains new backward-compatible features. |
| 21 | * A _patch release_ contains minor changes and bug fixes. |
| 22 | |
| 23 | Using version 3.5.1 as an example, a new release of each type would result in |
| 24 | these version numbers: |
| 25 | |
| 26 | * Major: 4.0 |
| 27 | * Minor: 3.6 |
| 28 | * Patch: 3.5.2 |
| 29 | |
| 30 | ## Bazel's release cycle |
| 31 | |
| 32 | Bazel continually publishes rolling releases. Every major version is an LTS |
| 33 | release. You can choose to follow either release cadence - updating from one |
| 34 | LTS release to the next, or updating with each minor version release. |
| 35 | |
| 36 | The image shows both rolling and LTS releases, and the expected support for |
| 37 | each. |
| 38 | |
| 39 | [!image](images/roadmap.png) |
| 40 | |
| 41 | ## Release branches |
| 42 | |
| 43 | Each major version becomes a separate development branch on release. You can |
| 44 | receive fixes to critical bugs on that branch without having to update to the |
| 45 | Bazel release at head. Additional features on your major version branch become |
| 46 | minor releases and the highest version on the branch is the supported version. |
| 47 | |
| 48 | Each Bazel release is paired with a list of recommended rule versions that work |
| 49 | together and there is strict backwards compatibility within each branch. |
| 50 | |
| 51 | ## LTS releases |
| 52 | |
| 53 | An LTS release is a major version (such as, 4.0) that is supported for 3 years |
| 54 | after its release. |
| 55 | A major version is released approximately every nine months. |
| 56 | |
| 57 | Ongoing development on a release branch results in minor versions. |
| 58 | |
| 59 | You can choose to pin your project to a major release and update to a newer |
| 60 | version in your own time. This gives you time to preview upcoming changes and |
| 61 | adapt to them in advance. |
| 62 | |
| 63 | ## Rolling releases |
| 64 | |
| 65 | Rolling releases are periodically cut from Bazel's main branch. |
| 66 | This release cadence involves a continuous delivery of preview releases of the |
| 67 | next major Bazel version, which are in sync with Google’s internal Bazel |
| 68 | releases. |
| 69 | |
| 70 | Note that a new rolling release can contain breaking changes that are |
| 71 | incompatible with previous releases. |
| 72 | |
| 73 | ## Updating versions |
| 74 | |
| 75 | * For more information on updating your Bazel version, see |
| 76 | [Updating Bazel](updating-bazel.html). |
| 77 | * For more information on contributing updates to new Bazel releases, see |
| 78 | [Contributing to Bazel](bazel.build/contributing.html). |
| 79 | |
| 80 | |
