Bazel LTS Release Cadence

[meteorcloudy]

The Bazel LTS Release Cadence Survey has been open for over a month, and we have received 46 responses (as of Apr 19th, 2023) in total from the community. We want to share the results and continue the discussion here to reach a decision.

Distribution of the roles of the respondents

• 12 respondents (26%) identified their main community role as “Bazel user” only.
• 34 respondents (74%) identified at least one of their community roles as “Bazel rules author” or “Bazel developer”.

Distribution of preferred LTS release frequency among all respondents

Distribution of preferred LTS release frequency among respondents identified as “Bazel user” only

Common themes in "Why do you prefer the selected frequency?"

For shorter release cycles (~6 months)

• Faster access to new features.
• Migration for each major release is easier if there are fewer changes.
• Less maintenance burden for rules authors to support older LTS releases (assuming we also deprecate LTS releases faster).

For longer release cycles (~12 months)

• Fewer interruptions to coordinate major updates for Bazel and rule sets (important for enterprise customers with tight resources).
• Aligned with yearly development plan and BazelCon, it is the correct cadence for Long-Term-Support release.
• Shipping more meaningful features besides breaking changes in a new major release.

Current preferred release model by the Bazel team

After carefully considering community feedback gathered from the survey and other channels, we are leaning to keep the current de facto 12-month LTS release cycle and continue to ship minor releases for the latest LTS release every two months to backport backwards-compatible bug fixes and new features requested by the community.

With this approach, Bazel users are able to benefit from enhancements with minor releases quickly, which requires zero migration effort. To make it easier to migrate for breaking changes in major releases, we plan to improve our incompatible change process to enable users to migrate in advance, more details in this doc. In the same doc, we also proposed best practices for rules authors to keep compatibility with different Bazel LTS releases, including starting a bazel_features repository to detect API changes in Bazel.

Please feel free to share your opinions on this!

[meteorcloudy]

Thanks for the thumbs ups! Bazel's release model has been updated now: https://bazel.build/release. we also added some best practices for rules authors to keep compatibility with Bazel, please check https://bazel.build/release/rule-compatibility.