Shipping a major version puts documentation in an awkward position. Rewrite the pages and you break every customer still running the old release. Leave them and you are lying to everyone on the new one. Bolt "(v1 only)" onto half your headings and you get a knowledge base nobody can read.
FinalDoc holds a complete set of documentation per version, and lets readers choose.
Readers pick a version
When more than one version is published, a dropdown appears in your documentation header showing the current one. Picking another swaps the whole site: navigation, categories, home page, and the articles themselves.
The scoping is real, not cosmetic. Search only returns results from the version the reader is on. So does autocomplete. Asking for a v1 article while browsing v2 returns a proper 404 rather than quietly serving content from the wrong release — which is the failure that makes versioned docs worse than none at all, because the reader has no idea they have crossed a boundary.
Build the next version in private
Each version has its own lifecycle: draft or published, public or private. That means you can build v2 while v1 is the only thing your customers can see, then make it live on release day.
You do not start from a blank page either. Cloning a version copies all of its categories and articles into a new one, so v2 begins as a copy of v1 and you edit the parts that changed. A cloned version is created as a draft and stays invisible to readers until you publish it deliberately — there is no window where half-edited v2 pages are live.
One thing to do first
If your knowledge base already has articles and you are adding versions for the first time, move the existing articles into a version as part of the switch.
Articles that predate versioning are not attached to one, and version-scoped navigation and search only show articles that belong to the version being viewed. There are admin tools to find unassigned content and move it into a version in bulk — do that in the same sitting, rather than discovering later that half your library has quietly dropped out of the sidebar.
What it is not
Worth being precise, because "versioning" means different things in different tools.
This is a switcher. A reader is on exactly one version at a time, and the site follows that choice everywhere. If you want to tell readers what changed between releases, write that page yourself — a human-written "what's new in v2" is more useful than anything generated, because it can say why the change was made.
It is also separate from revision history. Versions are for your product's releases. Revision history is for tracking edits to a single article. Most teams need both, for different reasons.
Who needs this
If you ship continuously and customers are always on the latest release, you do not need versions and should not add them — they are real overhead, because every fix has to be considered against every live version.
They earn their place when customers genuinely stay behind: on-premise software, SDKs and API clients, hardware firmware, anything with a long-term support release. In those products, "which version are you on" is the first question support asks, and documentation that cannot answer it makes every ticket longer.
Where to find it
Versions live under Settings → General → Knowledge Bases, and the reader-facing switcher can be turned off in your portal settings if you would rather link versions yourself.