Versions
In addition to the product variants, the docs site also supports multiple versions of the documentation. The version selector is located at the top of the page, next to the variant selector. Versions and variants are independent of each other, with the version being “above” the variant in the URL hierarchy.
The URL for version v1 of the current page (the one you are one right now) in the Flyte variant is:
https://www.union.ai/docs/v1/flyte/community/contributing-docs/versions
while the URL for version v2 of the same page is:
https://www.union.ai/docs/v2/flyte/community/contributing-docs/versions
What a version contains (and what it does not)
A docs version is a snapshot of content — the pages, examples and generated API
reference as they stood against a given SDK release. The site’s look and
navigation (the theme, built from the shared unionai-docs-infra submodule) is
not part of the snapshot: every published version, however old, is always served
with the current site UI. This is deliberate — the content you are reading has a
version; the reading experience should always be the best available.
Two practical consequences for contributors:
- Theme or build-system changes never require a new docs version. They reach every published version automatically when the infra submodule pointer is bumped on the docs branch.
- Content changes reach the stable version at the next cut.
Lines are branches; versions are cuts
Each major line lives on its own long-lived branch in unionai/unionai-docs:
maincarries the current line, v2, built against theflyte2.x SDK.v1carries this line, built againstflytekit1.x. It is active, not frozen: new flytekit 1.x releases still produce new v1 versions.
Within a line, a version is a cut: an immutable snapshot of the content against an SDK
release, tagged vN.x.y.z. N.x.y is the SDK release the docs were built against, and z is a
docs patch counter for when a secondary component releases but the SDK triple has not moved.
Which URL serves what
v1 is a secondary line, which changes what you see here:
| URL | Serves | Indexed |
|---|---|---|
/docs/v1 |
the newest v1 cut, this line’s canonical surface | yes |
/docs/v1.x.y.z |
an older, superseded v1 cut | no |
/docs/latest |
the v2 line’s tip, not v1’s. There is only one /docs/latest, and the primary line owns it |
no |
So there is no bleeding-edge URL for v1. A merged v1 page is not visible anywhere until the
next v1 cut, which is the main practical difference from contributing on main. If you need
to see a change before then, check the pull request’s preview build.
Cutting a v1 version
A cut is one merge. Running Cut a docs version or Regenerate API docs from the
Actions tab, with the branch set to v1, opens a draft pull request that bumps versions.toml.
Merging that PR is the cut: the build materializes the tag and rebuilds.
v1 cuts are started by hand. GitHub fires scheduled and repository-dispatch events only
from the default branch, so the automatic release signals run for the v2 line. A v1 bump uses
a manual workflow dispatch against the v1 branch.
Nothing auto-merges. Every path ends in a pull request a maintainer reviews.
Maintainer detail, including how many pinned versions are retained and how a retired pin gets its
redirect, lives in unionai-docs-infra/VERSIONING.md and CUTTING-A-DOCS-VERSION.md.