> For the complete documentation index, see [llms.txt](https://docs.weka.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.weka.io/5.1/support/release-support-and-commitments.md).

# Release support and commitments

Identify WEKA software versioning schema, support phases, and lifecycle policies to plan upgrades and maintain system stability.

WEKA software versions use a three-part numbering system: `Major.Minor.Revision`. For example, `5.1.2`.

<table><thead><tr><th width="141.03125">Level</th><th>Description</th></tr></thead><tbody><tr><td>Major</td><td>Indicates a feature release. WEKA bumps the Major number for high-impact, strategic changes. A new Major number opens a new Release Line.</td></tr><tr><td>Minor</td><td>Indicates a feature release within an existing Release Line. Minor releases are triggered by the same type of changes as Major releases. The choice between a Major and a Minor bump reflects the scope of the features and their market impact.</td></tr><tr><td>Revision</td><td>Indicates a cumulative service pack that includes bug fixes and currency updates. On the current line, it can also include enhancements and features.</td></tr></tbody></table>

## Release Lines

A Release Line is defined by a unique Major number. For example, 5.x, 6.x, and 7.x are each a distinct Release Line, and every Minor release within a Major number belongs to the same line. Version 5.1 belongs to the same Release Line as version 5.0.

Revisions are cumulative. Each higher revision includes all fixes from prior revisions within the same line.

In the WEKA portal at get.weka.io, each Release Line displays the Minor versions it contains. The current line appears as **5.0 / 5.1**, because both Minor versions belong to Major number 5.

<div data-with-frame="true"><figure><img src="https://2745724548-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZW262oqYA8pNNfGvXjHa%2Fuploads%2F3Njg3su3JGolSTEmcNEt%2Fversion_number.png?alt=media&amp;token=c487f065-52b9-4a61-aadc-34d88347b454" alt=""><figcaption><p><em>Version number structure and Release Line grouping</em></p></figcaption></figure></div>

{% hint style="info" %}
Legacy 4.x versions use Release Line groupings that differ from the Major number rule:

* Versions 4.0 and 4.1 share the same Release Line.
* Version 4.2 is a separate Release Line.
* Versions 4.3 and 4.4 share the same Release Line.
  {% endhint %}

## Support phases

The support phase for a Release Line changes as WEKA introduces newer versions.

<table><thead><tr><th width="181.51171875">Phase</th><th width="171.23046875">Status</th><th>Support details</th></tr></thead><tbody><tr><td>N</td><td>Current</td><td>Receives new features and service packs. This phase receives full engineering investment.</td></tr><tr><td>N-1</td><td>Maintenance</td><td>Receives ongoing service packs containing bug fixes and currency updates. No new features are added.</td></tr><tr><td>N-2</td><td>Limited Support</td><td>Receives selective fix releases on a case-by-case basis. This phase is supported by Customer Success and R&#x26;D jointly.</td></tr><tr><td>N-3 and older</td><td>End of Life</td><td>Receives no further updates. Upgrade immediately.</td></tr></tbody></table>

Service packs for Current and Maintenance phases include bug fixes and updates for operating systems, cloud instances, and network interface cards. For the Limited Support phase, currency and interoperability updates are provided on a best-effort basis with no committed service pack cadence.

<div data-with-frame="true"><figure><img src="https://2745724548-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZW262oqYA8pNNfGvXjHa%2Fuploads%2F4YhynG2OlZuWkjUSvIed%2Frelease_line_lifecycle.png?alt=media&amp;token=8d97f7bc-282a-4ccc-9ad5-633f8dcb5566" alt=""><figcaption><p>Release Line lifecycle: Support phase transitions (example)</p></figcaption></figure></div>

{% hint style="info" %}
This figure shows an example. Support phases change as new Release Lines are introduced.
{% endhint %}

## Lifecycle policy

WEKA provides a unified support framework to ensure predictability and simplify compliance.

* **Support duration:** Every Release Line receives 36 months of support starting from its initial General Availability release.
* **New Release Lines:** WEKA introduces a new Release Line approximately every 12 months.

{% hint style="info" %}
WEKA no longer uses LTS or Innovation labels to ensure every release is recognized for its high stability and long-term commitment. Removing these labels creates a transparent, simplified framework that provides clear planning for all deployments.
{% endhint %}

## Check the support phase of a Release Line

Identify the current phase and End of Life date of your Release Line before planning an upgrade.

1. Sign in to the WEKA portal at get.weka.io.
2. Select **Release Lines**.
3. Locate your Release Line.

Each Release Line shows its support phase, its End of Life date, and the releases it contains. The line marked **N. Current** carries the newest features.

## Related topics

[Upgrade WEKA versions](/5.1/operation-guide/upgrading-weka-versions.md)

[Get support for your WEKA system](/5.1/support/getting-support-for-your-weka-system.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.weka.io/5.1/support/release-support-and-commitments.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.