Implement version picker in a simple way

[albertomercurio]

Hello,

DocumenterVitepress.jl seems not to natively support the version picker (the possibility to choose the version of the package to show).

Looking at Lux.jl or Makie.jl, they customize the vitepress files in the docs folder, and they also add an additional CI in the gh-pages branch. Is it the simplest way to do it?

When using Documenter.jl, a single CI in the main branchis sufficient to deploy the documentation. Here, instead, we need to add an additional CI also in thegh-pages` branch, which I think is only needed to fix the symbolic links for vitepress (whatever it means).

With this in mind, I was wondering if pushing two commits in quick succession to the main branch could cause any issues with deployment. Additionally, I noticed that the history of the gh-pages branch is cleared every time the CI runs, which is concerning to me.

Finally, would it be possible to implement the version picker directly in DocumenterVitepress.jl? In this way, it would align more with Documenter.jl

[lazarusA]

Finally, would it be possible to implement the version picker directly in DocumenterVitepress.jl? In this way, it would align more with Documenter.jl

I believe this is already working on master.

When using Documenter.jl, a single CI in the main branchis sufficient to deploy the documentation. Here, instead, we need to add an additional CI also in thegh-pages` branch, which I think is only needed to fix the symbolic links for vitepress (whatever it means).

Yes, totally. PRs are welcome. It would be preferably to do it directly in the build config.mts options. I looked at this some weeks ago, but I had other obligations 😄 .

Additionally, I noticed that the history of the gh-pages branch is cleared every time the CI runs, which is concerning to me.
?

[albertomercurio]

I believe this is already working on master.

Great! Does this mean that in the next release I can have the version picker without doing anything else? Do I still have to follow some procedure? Does the version picker cover all the previous version as in Documenter.jl?

Sorry for the many questions. This is just curiosity. 😄

It would be preferably to do it directly in the build config.mts options. I looked at this some weeks ago, but I had other obligations 😄 .

Great again! Does this mean that, by changing config.mts we can avoid to have an additional CI in the gh-pages (and then approaching to the simpler case of Documenter.jl)?

Additionally, I noticed that the history of the gh-pages branch is cleared every time the CI runs, which is concerning to me.
?

I mean that for example in the gh-pages branch here, it cancels the commits history every time it deploys.

[thofma]

With this in mind, I was wondering if pushing two commits in quick succession to the main branch could cause any issues with deployment. Additionally, I noticed that the history of the gh-pages branch is cleared every time the CI runs, which is concerning to me.

This is unrelated to DocumenterVitepress. It is a separate action described here: https://documenter.juliadocs.org/stable/man/hosting/#Cleaning-up-gh-pages.

[thofma]

Also, the separate deployment action is also unrelated to the version picker. It is added as a workaround for
#81.

[albertomercurio]

Also, the separate deployment action is also unrelated to the version picker. It is added as a workaround for
#81.

So the version picker is unrelated to #81 (which has something to do with symlink instead). As far as I understand, the symlinks of Vitepress are not exactly compatible with how Julia handles versions, right?

So, the version picker has nothing to do with the additional CI in the gh-pages as soon as the symlinks work (almost never). Am I right?

The version picker of the master branch of DocumenterVitepress.jl seems to work only for the stable and dev channels, but it doesn't work for v0.1.