P.4 Bazel as a Project

Bazel is not only a build model. It is also an open-source project with releases, version support, maintainers, rulesets, registries, and community tools. A real repository depends on a specific Bazel version and on ecosystem pieces that may be maintained by different people.

History, Versions, And Ownership

The three articles move from background to practical project concerns.

P.4.1 Historical Arc & Blaze Origin explains the history behind Bazel's artifact-based model. It connects the task-vs-artifact idea from P.2.1 Task-Based vs Artifact-Based to the wider family of build tools discussed in P.3.3 Alternative Build Systems.

P.4.2 Release Cadence & LTS is the most practical article in the section, and the place to start if you will be operating a repository soon. It explains rolling releases, LTS releases, incompatible flags, experimental flags, and why projects usually pin one exact Bazel version.

P.4.3 Governance & Community explains ownership. Google leads core Bazel, but many rulesets, registry entries, and tools are maintained across the wider community.

Why This Matters For A Team

Adopting Bazel also means adopting version and ownership discipline. The build model matters, but so does the exact Bazel version, the rulesets you depend on, and the community or vendor maintaining them.

A repository without a pinned Bazel version can behave differently across machines. A team that treats every ruleset issue as a core Bazel issue may look in the wrong place for help. A migration discussion that ignores history may miss why build tools keep returning to the task-vs-artifact trade-off.

Common Beginner Confusions

The first confusion is version drift. If the repository does not pin the Bazel binary, two developers may not be running the same build tool. P.4.2 Release Cadence & LTS connects this to Bazelisk and .bazelversion.

The second confusion is ownership. Core Bazel, rulesets, the Bazel Central Registry, and community-maintained tools do not all have the same owner or the same release process. P.4.3 Governance & Community makes those layers visible.

Keep everyday builds pinned to one exact Bazel version. Use floating labels such as rolling, last_rc, or broad series pins only for canaries, upgrade tests, or planned migration work.