> ## Documentation Index
> Fetch the complete documentation index at: https://zenskar.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Versioning logic

This page defines the version string format used across Zenskar's documentation and backend builds, who owns each segment of that string, and how a version string maps to a set of documentation files. For the current mapping between documentation versions and backend builds, see the [compatibility matrix](/docs/meta/matrix).

## 1. Version string format

```
{tree_name}[.{quality}].{backend_calver}
```

| Example | Meaning |
| - | - |
| `cedar.20260301` | Stable |
| `cedar.RC.20260301` | Release candidate |
| `deodar.BETA.20260815` | Beta |

| Segment | Meaning |
| - | - |
| `tree_name` | Identifies the release. Single word, assigned alphabetically. |
| `quality` (optional) | Pre-release marker: `ALPHA`, `BETA`, or `RC`. Omitted for stable builds. |
| `backend_calver` | Backend build date, `yyyymmdd`. |

### tree\_name

A single-word tree or plant name, assigned alphabetically per release (`cedar`, then `deodar`, and so on). Always a single word, never compound (no "umbrella tree").

### quality

Present only during pre-release states, always one of `ALPHA`, `BETA`, or `RC`, in that order. Omitted entirely for stable builds, so a stable version string has exactly two dot-separated segments: `tree_name.backend_calver`. There is no literal `STABLE` marker; the absence of `quality` is itself what signals a stable build.

### backend\_calver

The backend build's date, in [CalVer](https://calver.org) `yyyymmdd` format. Globally unique per build. Identifies a backend build only and carries no compatibility information on its own. See the [compatibility matrix](/docs/meta/matrix) for that.

## 2. Ownership

| Segment | Set by | Cadence |
| - | - | - |
| `tree_name` | Product | Per release |
| `backend_calver` | Backend | Per build |
| Compatibility matrix | Docs | Per new `backend_calver` |

## 3. Documentation versions

A documentation version is the full `tree_name[.quality].backend_calver` string (e.g. `cedar.20250901`, `deodar.BETA.20260210`). There is no separate label distinct from this string. Each documentation version corresponds to one version entry in the site's navigation configuration (the `version` field in `nav/<backend_calver>/<backend_calver>.json`), named after that full string, and one complete set of page files.

### 3.1 File independence across versions

Each documentation version has its own complete, duplicated copy of every page. Files are never shared or linked across versions. See the repository's `README.md` for the resulting folder and navigation conventions when adding or editing content.

### 3.2 Compatibility banner

Every page must carry a short banner near the top stating the documentation version it belongs to and, where its content was last verified under a different version's structure, which version that was. For example:

> This page is current as of `deodar.BETA.20260210`. It was last updated under `cedar.20250901`'s docs structure. The content still applies.

If content differs between versions, the banner must say so explicitly rather than imply full parity.

## Summary

* Version string: `tree_name[.quality].backend_calver`.
* `tree_name`: single word, alphabetical, set by product.
* `quality`: `ALPHA`, `BETA`, or `RC` only; omitted for stable builds.
* `backend_calver`: backend build date (CalVer `yyyymmdd`), globally unique, set by backend.
* A documentation version is the full version string; there is no separate label.
* Documentation files are duplicated per version, never shared.
* Every page must carry a compatibility banner.
* See the [compatibility matrix](/docs/meta/matrix) for which backend builds a documentation version covers.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.