From 8486adc797c1fc976c8a57b66ac2ac66bf3f9a22 Mon Sep 17 00:00:00 2001 From: Steven Hicks Date: Wed, 4 May 2022 10:38:42 -0500 Subject: [PATCH] docs: add clarity to versioning behavior --- website/docs/guides/docs/versioning.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/guides/docs/versioning.md b/website/docs/guides/docs/versioning.md index 40eb0a2f23ac..e27512e083a6 100644 --- a/website/docs/guides/docs/versioning.md +++ b/website/docs/guides/docs/versioning.md @@ -161,7 +161,7 @@ Example: The "current" version is the version name for the `./docs` folder. There are different ways to manage versioning, but two very common patterns are: -- You release v1, and start immediately working on v2 (including its docs). In this case, the **current version** is v2, which is in the `./docs` folder, while the **latest version** is v1, which is the version hosted at `example.com/docs` and is browsed by most of your users. +- You release v1, and start immediately working on v2 (including its docs). In this case, the **current version** is v2, which is in the `./docs` source folder, and can be browsed at `example.com/docs/next`. The **latest version** is v1, which is in the `./versioned_docs/version-1` source folder, and is browsed by most of your users at `example.com/docs`. - You release v1, and will maintain it for some time before thinking about v2. In this case, the **current version** and **latest version** will both be point to v1, since the v2 docs doesn't even exist yet! Docusaurus defaults work great for the first use case. We will label the current version as "next" and you can even choose not to publish it.