Ownership
Helix is maintained as a platform product. That means changes are evaluated not only for individual modules, but also for how they affect the ecosystem as a whole.
The Helix maintainers are responsible for:
- roadmap and product direction across templates, CLI, plugins, starters, libraries, and docs
- review of compatibility-sensitive changes
- release sequencing and validation
- issue triage and ecosystem-wide quality
In practice, the most important question is not “does this module build?” It is “does this change keep Helix coherent as a framework?”
Release Discipline
Helix releases are coordinated through the monorepo rather than managed as disconnected projects.
The release workflow emphasizes:
- consistent versioning and publish flow
- validation across templates, plugins, CLI, and shared build logic
- documentation updates that stay aligned with real behavior
For contributor-facing release details, see the release guide in the repository developer docs.
Compatibility-Sensitive Changes
Some changes have platform-wide impact and should be treated with extra care:
- generated project structure changes in templates
- CLI command or option changes
- Gradle plugin convention changes
- dependency policy or version-catalog changes
- starter or library changes that alter common runtime behavior
When those changes are made, Helix expects the corresponding docs and adoption guidance to be updated in the same change whenever possible.
Docs Hygiene
Helix treats documentation as part of the product surface.
That means:
- CLI docs should reflect the actual shipped commands
- template docs should reflect the actual generation workflow
- shared patterns should live in shared layouts, styles, or generated data when possible
- reference material should point to real destinations and working artifacts, not placeholders
The goal is simple: if an evaluator or adopter follows the docs, the product should behave the way the docs say it behaves.