# Version and release model

The dedicated Omni documentation repository keeps the current portal and immutable product-release snapshots distinguishable.

## Current documentation

The repository's `main` branch is the production source for `omni-api-docs.percents.com`. It contains the latest compatible guidance, OpenAPI contract, and changelog.

Documentation publication timestamps are not API version timestamps. A documentation-provider migration, hosting change, or editorial update can produce a newer site timestamp while the public API remains on the same version. The changelog's **Most recent API update** date is the client-facing source of truth for a version's latest contract update.

## Tagged product releases

When a tagged product release changes `clo-api-docs/`, publication creates matching documentation Git references:

| Product release | Docs branch | Docs tag | Redocly version label |
|  --- | --- | --- | --- |
| `v1.4.0` | `release/v1.4.0` | `v1.4.0` | `v1.4.0` |


The release branch is built from the exact tagged product commit. The matching docs tag points to that published snapshot. Redocly should expose the branch or tag as the corresponding selectable Omni documentation version.

## Adding future release notes

For every client-visible contract change:

1. Add a Markdown entry under `changelog/releases/`.
2. Link it from the changelog sidebar and landing page, newest first.
3. Describe additions, behavior changes, deprecations, breaking changes, and migration actions.
4. Update the OpenAPI document and conceptual guides in the same product change.
5. Publish the product tag so the release branch, docs tag, and Redocly version all refer to the same source commit.


Documentation-only fixes can land on docs `main` without creating a product release entry. They must not silently change the public API contract.