P.4 Bazel as a Project

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

History, Versions, And Ownership

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.

A Versioned And Layered Dependency

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.

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.