@spzala et al: I'd like to propose that all our doc version subfolders name the version they are targeting. That is currently the case except for the special /docs/next.
Some drawbacks of using /docs/next as part of permalinks include the following:
- This muddles analytics
- It makes releasing a new version of the docs a bit more work. For details, see the following threads:
- In my opinion, it can confuse site users as explained next:
Let's suppose that we just released v3.5 docs, under the current scheme we'd already have a /docs/next even though there are no v3.6.x-DRAFT docs. Under the new scheme we can either, not create v3.6 until we have v3.6 docs, or we can immediately create the branch but mark it as draft and not publish it (until we have actual v3.6 specific changes).
Some advantages of using only a version name for doc-version subfolders:
- We can have more than one "next". For example, etcd currently has v3.5 and v4.0 under development.
We can, of course, keep /docs/next as a virtual path that is redirected to the/a "next" release of the docs.
Thoughts?
Related:
Following, #336, we'll need to consider the impact (and possible improvements) to the Makefile.
/cc @nate-double-u
@spzala et al: I'd like to propose that all our doc version subfolders name the version they are targeting. That is currently the case except for the special
/docs/next.Some drawbacks of using
/docs/nextas part of permalinks include the following:Let's suppose that we just released v3.5 docs, under the current scheme we'd already have a
/docs/nexteven though there are no v3.6.x-DRAFT docs. Under the new scheme we can either, not create v3.6 until we have v3.6 docs, or we can immediately create the branch but mark it as draft and not publish it (until we have actual v3.6 specific changes).Some advantages of using only a version name for doc-version subfolders:
We can, of course, keep
/docs/nextas a virtual path that is redirected to the/a "next" release of the docs.Thoughts?
Related:
Following, #336, we'll need to consider the impact (and possible improvements) to the
Makefile./cc @nate-double-u