Compatibility

Platform Baseline

Helix is built for modern Java and Spring Boot teams that want a more standardized platform baseline across repositories.

Current baseline expectations:

• JDK 17 or newer
• Gradle-based build workflows
• Spring Boot as the primary application model
• Helix CLI available for template-driven project generation

Supported Workflow

Helix works best when adopters use it as a coordinated platform rather than picking isolated pieces at random.

The typical supported flow is:

1. Generate from a Helix template.
2. Build with the Helix Gradle conventions applied through plugins and shared build logic.
3. Add starters and libraries that match the platform capabilities you want to standardize.
4. Use the docs and release guidance to keep upgrades aligned over time.

Teams can adopt Helix incrementally, but the framework delivers the most value when templates, plugins, starters, libraries, and CLI workflows stay aligned.

Version Alignment

For the smoothest adoption path, evaluate Helix as a release train.

That means:

• avoid mixing unrelated snapshots and older stable versions across the ecosystem when possible
• verify template, plugin, starter, and library compatibility together during upgrades
• treat build logic and generated project structure as compatibility-sensitive surfaces

If your organization has strict change-control requirements, test Helix updates in a representative application before rolling them out broadly.

Breaking Changes

Changes should be considered breaking when they materially affect how adopters generate, build, configure, or run Helix-based projects.

Examples include:

• removing or renaming CLI commands or options
• changing generated project structure in a way that affects automation or onboarding
• changing plugin conventions that alter build outcomes
• introducing incompatible runtime configuration expectations in starters or libraries

When changes like these happen, they should be called out explicitly in release communication and reflected in the docs.

Support Expectations

Helix is best suited for teams that want a maintained standard, not just a one-time code generator.

You should expect to:

• keep your teams reasonably current with Helix releases
• review release notes and compatibility guidance during upgrades
• treat framework adoption as a platform decision with ownership, not just a dependency choice

If your team wants maximum local variation and minimal shared policy, Helix is likely more opinionated than you need.