Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.thoras.ai/llms.txt

Use this file to discover all available pages before exploring further.

This policy describes how Thoras supports customers, communicates changes, and maintains stability across releases. The model is designed so that staying up to date is safe and straightforward: every release contains the latest fixes, upgrades within a major version do not require migration work, and any change that would require migration is communicated well in advance.

​
Supported versions

Thoras ships continuously. Bug fixes and security patches are included in every release, and customers receive them by upgrading to the latest version. Because Thoras maintains strict compatibility within a major version (described below), upgrades within a major are designed to be safe and routine: no migration work, no breaking changes, no surprises. Previous release branches are not maintained.

​
Compatibility within a major version

Within a major version, Thoras does not introduce breaking changes to:
  • AIScaleTarget, ClusterAIScaleTemplate, and other documented Custom Resource Definitions
  • Helm chart values (no renames or removals without the deprecation process described below)
Behavior improvements that do not alter the interfaces listed above (forecasting accuracy, internal defaults, performance) may ship in any minor or patch release. This compatibility commitment is the foundation of the support model: because nothing breaks between releases within a major version, customers can confidently apply the latest release whenever they need a fix.

​
APIs

Thoras APIs are internal. They are not part of the public product surface, are not covered by this policy, and may change in any release without prior notice. Customers who require a stable API should contact their Thoras Product Adoption Engineer. Any API stability commitment requires a separate written agreement and is not implied by this policy.

​
Breaking changes

Breaking changes to the interfaces listed under “Compatibility within a major version” are reserved for major version releases. Before a major release, Thoras will provide:
  • At least 90 days written notice via release notes, the documentation site, and email to listed customer contacts
  • A migration guide
The 90-day notice period gives customers time to plan and execute the migration. When the new major reaches general availability, support consolidates on the new version. For migrations that need additional time or coordination, customers should engage their Product Adoption Engineer; Thoras works directly with customers to make these transitions successful.

​
Kubernetes version support

Thoras supports the five most recent upstream Kubernetes minor versions. When a new upstream minor reaches general availability, the oldest supported version is dropped at the next Thoras release. The current list of supported versions is published in each Thoras release notes. Older versions may continue to work but are not part of the Thoras test matrix and compatibility is not guaranteed.

​
Deprecations

Any field or behavior marked deprecated within the interfaces listed under “Compatibility within a major version” will continue to function for at least 90 days from the deprecation announcement before removal. Deprecations are listed in release notes at the time of announcement and tracked at docs.thoras.ai/deprecations, giving customers lead time to adjust.

​
Out of scope

  • Alpha and beta features carry no compatibility or deprecation guarantee. They may change or be removed at any time.
  • Behaviors not described in the public documentation are not covered by this policy.

​
Questions

For questions about this policy or about a specific upgrade or migration, email support@thoras.ai or contact your Thoras Product Adoption Engineer.