First off: I think this would be a great addition and really helpful, especially if using something like semantic-release to auto create versions and package the correct docs with it.

One potentiell issue I see would be the linking of source files as examples. When using a git tag as the version there should be some kind of variable or variable replacement that allows to reference the correct file from the rev that is the version.

Here is an example:

I have an embedded code fragment I want to display in my docs and use the following syntax to embed it:

[filename](../src/app/js/example.js ':include :type=code :fragment=demo')

What would this display after the cli version command copied all of the files? Always the master branch? Will it be copied as well? If yes, where?

One solution to this (I can think of) would be to add a ref tag to the embed snippet that defaults to master, but also takes a variable that can be resolved to the current version.

[filename](_media/example.js ':include :type=code :fragment=demo :rev=$version')

What do you think?

I am not planning of using tags for versioning instead, using folder structure. So whenever versioning is being done, you will a new folder named <version name/number> and inside that everything will be the same as it was before the versioning.

Hi, in my opinion there should still be an option to convert git tags to docsify versions. In the long run, you could for example provide a GitHub action that updates the versions with docsify-cli on every tag pushed to GitHub. There could also be a dev version, which contains the documentation of the current master branch.
Of course, the difficulty here would be to automatically generate the documentation up to a certain tag.

The steps that would be necessary for this:

1. docsify version is executed
2. docsify gets all git tags by executing git tags
3. for each tag:
   1. git checkout tag-name
   2. the documentation is generated and temporarily stored
   3. git checkout master
   4. the documentation is saved in /docs/tag-name
4. here follows the _navbar.md generation, but @anikethsaha has already described it.

Creating a GitHub action would be easy with this functionality and would automatically list each pushed tag as a new version in the documentation, which would eliminate the struggle to update the docs versions manually.

@anikethsaha While a nice solution, that would create quite a large impact on repo size over time. Tools that use git as their underlying versioning system would increase the volume of code served to their users as the documentation changes across versions might generate a small or zero git diff but large size when measured by a simple copy.

@MarvinJWendt Github action sounds great helper.
@jthegedus yeah , you have a good point about the repo size. Thanks for bringing this.

Can you guys create a polished proposal for your solution? I would love to read them and we might change this proposal to the new one if that fits well. You can comment here with the above template.

I have no idea if this is feasible.

Design (not so detailed)

My initial thoughts were that given we have the Repo URL and the filepath within a given folder that we could fetch the files via git tag as we would for files like https://raw.githubusercontent.com/docsifyjs/docsify/v4.11.5/README.md.

The complexity is how Docsify would reload to re-render these files while keeping the configuration of the user's selection. Perhaps via query params or localstorage.

So for a homepage we would get:

• on initial load: https://raw.githubusercontent.com/docsifyjs/docsify/master/README.md
• after selecting a version: https://raw.githubusercontent.com/docsifyjs/docsify/v4.11.5/README.md

Perhaps this can be taken care of with the existing basePath configuration where it gets rewritten on version select?

The actual list of versions would need to be populated by performing a fetch to the listed repo's platform's API. EG: GitHub https://docs.github.com/en/rest/reference/repos#list-repository-tags

The value I (and others in my circles) get from Docsify is the fact it doesn't require a redeploy each time docs change. It's all client-side and set and forget. If we can provide versioning support in the same way that would be ideal IMO.

Other

• users could define the default tag to be master or a version number if they wish to pin to a stable release of their tool
• requires a full reload for Docsify to render the selected version of pages (unsure if this would be different from the initial proposal)

Hi,

Maybe we could just create a branch (called "docs"), containing a docs/version-xx.xx directory, including only documentation in html format ? (not markdown)

Any developments on this proposal?

Hi everyone, thanks for the amazing tool. Any progress on this proposal? This feature would be really useful.

I second @Piotr1215 and @FaultyFunctions
Any progress here? Versioning the docs is a really important feature. Current workaround with manually creating other docsify-folders with older versions and then linking to them is a pain.
In my opinion the growing repo size would be acceptable.

I second @Piotr1215 and @FaultyFunctions. Versioning is something a lot of people need. Would be great to see progress.

Is it something like this?

The source sode -> https://github.com/keiyin-wong/docsify-version-plugin

The docsify demo code -> https://github.com/keiyin-wong/docsify-version-plugin-doc-example
The live demo example website -> https://keiyin-wong.github.io/docsify-version-plugin-doc-example/docs/#/

@keiyin-wong that's very good!

Isn’t there still no progress on the proposal made four years ago? Version management is all too common for product documentation

@Niceies Feel free to make a PR. 😄

我同意@Piotr1215 和@FaultyFunctions 有什么进展吗？对文档进行版本控制是一项非常重要的功能。当前的解决方法是手动创建其他包含旧版本的 docsify 文件夹，然后链接到它们，这很麻烦。 在我看来，不断增长的 repo 大小是可以接受的。

请问到如今2024年，你的文档编写的方式迁移到别处了么？