Integration with mike version control

[kyleescobar]

I have not been able to figure out how to get mkdocs mike version provider to work. According to the mkdocs documentation, to publish a version to mike, a command must be executed.

https://squidfunk.github.io/mkdocs-material/setup/setting-up-versioning/#usage

Is there any support for this?

[xvik]

In short, no.

When I did this plugin mike didn't exist yet (it's funny but mike and the plugin were born in the same year/month) and so I implemented a very similar solution manually.
In terms of publication, it is completely equivalent to mike. The only downside is that you can't have that nice version switcher inside the doc (the switcher has also appeared just recently).

Still, I would suggest using custom publishing for now.

I'm not sure if it would be possible to use mike with the plugin. Essentially, mkdocs plugin built on top of gradle python plugin, so it is possible to add additional pip dependency on mike and write custom python tasks to call mike commands instead. Great chance that it would work.

Sorry, can't provide an example right now because it would require some time to read docs and trying, which I don't have right now.

But I will come back to this topic later and maybe will prepare such an example (because I want a version switcher for my projects docs too!).
Or, possibly, I will not use mike and instead write a material adapter for my way of publication (at least for now I see the only problem in version switcher absence).

The problem with mike is that it's limited to docs, whereas my way allows attaching javadoc or some other additions into generated documentation (for sure it's solvable for mike too, but need to compare what's eventually better, especially in the context of gradle). The other problem is that mike substitutes build step by itself, which may be a problem for the current gradle plugin too... Need to look everything closer.

[kyleescobar]

In short, no.

When I did this plugin mike didn't exist yet (it's funny but mike and the plugin were born in the same year/month) and so I implemented a very similar solution manually.
In terms of publication, it is completely equivalent to mike. The only downside is that you can't have that nice version switcher inside the doc (the switcher has also appeared just recently).

Still, I would suggest using custom publishing for now.

I'm not sure if it would be possible to use mike with the plugin. Essentially, mkdocs plugin built on top of gradle python plugin, so it is possible to add additional pip dependency on mike and write custom python tasks to call mike commands instead. Great chance that it would work.

Sorry, can't provide an example right now because it would require some time to read docs and trying, which I don't have right now.

But I will come back to this topic later and maybe will prepare such an example (because I want a version switcher for my projects docs too!).
Or, possibly, I will not use mike and instead write a material adapter for my way of publication (at least for now I see the only problem in version switcher absence).

The problem with mike is that it's limited to docs, whereas my way allows attaching javadoc or some other additions into generated documentation (for sure it's solvable for mike too, but need to compare what's eventually better, especially in the context of gradle). The other problem is that mike substitutes build step by itself, which may be a problem for the current gradle plugin too... Need to look everything closer.

Im going to work on this since i basically need it. If it get it working I can make a PR.

[xvik]

Integration for doc version switcher component added in 2.2.0 release. But it does not use mike: as before, custom publication mechanism used. Now it could work the same way as mike: aliases support added and (optional) root redirection to alias.

For mkdocs-material nothing special should be done: component activation is the same as in doc. It actually requires only versions.json file, published in the repository root. Plugin now automatically generates such file (in mike format), so mkdocs-material is happy.

More details on migrations page and usage demonstrated in new examples reference