2020-10-25 16:14:02 +01:00
|
|
|
---
|
|
|
|
template: overrides/main.html
|
|
|
|
---
|
|
|
|
|
|
|
|
# Setting up versioning
|
|
|
|
|
|
|
|
Material for MkDocs makes it easy to deploy multiple versions of your project
|
|
|
|
documentation by integrating with external utilities that add those capabilities
|
|
|
|
to MkDocs, i.e. [mike][1]. When deploying a new version, older versions of your
|
|
|
|
documentation remain untouched.
|
|
|
|
|
|
|
|
[1]: https://github.com/jimporter/mike
|
|
|
|
|
|
|
|
## Configuration
|
|
|
|
|
|
|
|
### Versioning
|
|
|
|
|
|
|
|
[:octicons-file-code-24: Source][2] ·
|
2021-02-27 09:14:15 +01:00
|
|
|
[:octicons-package-24: Utility][1]
|
2020-10-25 16:14:02 +01:00
|
|
|
|
|
|
|
[mike][1] makes it easy to deploy multiple versions of your project
|
|
|
|
documentation. It integrates natively with Material for MkDocs and can be
|
|
|
|
enabled via `mkdocs.yml`:
|
|
|
|
|
|
|
|
``` yaml
|
|
|
|
extra:
|
|
|
|
version:
|
2021-02-22 21:01:04 +01:00
|
|
|
provider: mike
|
2020-10-25 16:14:02 +01:00
|
|
|
```
|
|
|
|
|
|
|
|
This will render a version selector in the header next to the title of your
|
|
|
|
project:
|
|
|
|
|
2020-12-21 17:38:58 +01:00
|
|
|
<figure markdown="1">
|
2020-12-22 14:20:20 +01:00
|
|
|
|
|
|
|
[![Version selection][3]][3]
|
|
|
|
|
2020-12-21 17:38:58 +01:00
|
|
|
<figcaption markdown="1">
|
2020-12-22 14:20:20 +01:00
|
|
|
|
|
|
|
A demo is worth a thousand words — check it out at
|
|
|
|
[squidfunk.github.io/mkdocs-material-example-versioning][4]
|
|
|
|
|
2020-12-21 17:38:58 +01:00
|
|
|
</figcaption>
|
|
|
|
</figure>
|
2020-10-25 16:14:02 +01:00
|
|
|
|
|
|
|
!!! quote "[Why use mike?][5]"
|
|
|
|
|
|
|
|
mike is built around the idea that once you've generated your docs for a
|
|
|
|
particular version, you should never need to touch that version again. This
|
|
|
|
means you never have to worry about breaking changes in MkDocs, since your
|
|
|
|
old docs (built with an old version of MkDocs) are already generated and
|
|
|
|
sitting in your `gh-pages` branch.
|
|
|
|
|
|
|
|
While mike is flexible, it's optimized around putting your docs in a
|
|
|
|
`<major>.<minor>` directory, with optional aliases (e.g. `latest` or `dev`)
|
|
|
|
to particularly notable versions. This makes it easy to make permalinks to
|
|
|
|
whatever version of the documentation you want to direct people to.
|
|
|
|
|
2020-12-21 17:38:58 +01:00
|
|
|
_Note that you don't need to run_ `mike install-extras` _as noted in the
|
2020-10-25 17:03:19 +01:00
|
|
|
[official documentation][6], as [mike][1] is now natively integrated with
|
|
|
|
Material for MkDocs._
|
|
|
|
|
2021-02-22 21:01:04 +01:00
|
|
|
[2]: https://github.com/squidfunk/mkdocs-material/blob/master/src/partials/header.html
|
2020-10-25 16:14:02 +01:00
|
|
|
[3]: ../assets/screenshots/versioning.png
|
2020-10-25 17:03:19 +01:00
|
|
|
[4]: https://squidfunk.github.io/mkdocs-material-example-versioning/
|
2020-10-25 16:14:02 +01:00
|
|
|
[5]: https://github.com/jimporter/mike#why-use-mike
|
2020-10-25 17:03:19 +01:00
|
|
|
[6]: https://github.com/jimporter/mike#usage
|
2020-10-25 16:14:02 +01:00
|
|
|
|
|
|
|
## Usage
|
|
|
|
|
|
|
|
While this section outlines the basic workflow for publishing new versions,
|
2021-03-07 01:48:58 +01:00
|
|
|
it's best to check out the [official documentation][6] to make yourself familar
|
2020-10-25 16:14:02 +01:00
|
|
|
with [mike][1].
|
|
|
|
|
|
|
|
### Publishing a new version
|
|
|
|
|
2020-10-25 17:03:19 +01:00
|
|
|
If you want to publish a new version of your project documentation, choose a
|
2020-10-25 16:14:02 +01:00
|
|
|
version identifier and update the alias set as the default version with:
|
|
|
|
|
|
|
|
```
|
2020-10-25 17:03:19 +01:00
|
|
|
mike deploy --push --update-aliases 0.1 latest
|
2020-10-25 16:14:02 +01:00
|
|
|
```
|
|
|
|
|
|
|
|
Note that every version will be deployed as a subdirectory of your `site_url`,
|
|
|
|
e.g.:
|
|
|
|
|
|
|
|
- _docs.example.com/0.1_
|
|
|
|
- _docs.example.com/0.2_
|
|
|
|
- ...
|
2020-10-25 17:03:19 +01:00
|
|
|
|
|
|
|
### Setting a default version
|
|
|
|
|
|
|
|
When starting with [mike][1], a good idea is to set an alias as a default
|
|
|
|
version, e.g. `latest`, and when publishing a new version, always update the
|
|
|
|
alias to point to the latest version:
|
|
|
|
|
|
|
|
```
|
|
|
|
mike set-default --push latest
|
|
|
|
```
|
|
|
|
|
|
|
|
When publishing a new version, [mike][1] will create a redirect in the root of
|
|
|
|
your project documentation to the version associated with the alias:
|
|
|
|
|
|
|
|
_docs.example.com_ :octicons-arrow-right-24: _docs.example.com/0.1_
|