Versioning Strategy for slateui-theme

[JoshuaAlzate]

Discussion: Versioning Strategy for slateui-theme

Given that slateui-theme is tightly coupled to Angular’s ecosystem and relies on Angular-specific build tooling, it makes sense for the package’s versioning to follow Angular’s major versioning scheme.

Most Angular-focused libraries already use this approach—for example, Angular Material, CDK, NgRx, NGXS, Apollo Angular, Transloco, and many others. It creates a predictable alignment between framework changes and library compatibility, especially as Angular moves quickly with major releases.

Why follow Angular’s major versions?

• Clear compatibility signal
  If the version is 20.x.x, users immediately know it’s intended for Angular 20.x projects.

• Easier upgrades
  When Angular bumps to 21, the library can release 21.0.0, making dependency upgrades straightforward and avoiding confusion around compatibility tables.

• Avoids mismatched expectations
  A standalone semantic version (e.g., 1.4.0) suggests a stable API, but Angular upgrades may introduce required breaking changes. Aligning major versions avoids this mismatch.

• Community norms
  The wider Angular ecosystem already expects libraries to match Angular major versions, so developers understand what to install without reading compatibility charts.

Proposed approach

• Adopt major version parity with Angular
  • [email protected] → for Angular 20
  • [email protected] → for Angular 21
• Follow normal semantic versioning for minor + patch:
  • 20.1.0 → new components, theme tokens, or optional features
  • 20.1.1 → bug fixes or internal improvements

Benefits for contributors & maintainers

• Simplifies maintenance during Angular upgrade cycles.
• Reduces support questions around which version works with which Angular project.
• Encourages clearer documentation and smoother developer experience.