Versioning of the documentation

[javahippie]

As we now have reached version 1.0.0 and are collecting the scope vor version 1.1.0, I wonder if it makes sense to start doing versioning in out documentation page to avoid confusing our users and making clear which features are present in which verison.

[kthoms]

First, I would tag the documentation in the source. Next, I would create a "release" that packages that state as asset. When we have done this we could at any time provide older versions at subpaths, e.g. https://docs.operaton.org/versions/1.0 (intentionally leaving out the patch level).
In the current documentation new features should be marked with "since x.y".

[kthoms]

Maybe we could just start with setting up a release workflow with jreleaser, this would do the tagging, packaging and releasing for us.

[a-m-zill]

@javahippie this is a good point and i have planned to bring up this feature of docusaurus after all links are fixed.

This would be then also easier for managing the release version in all documentation pages and we can handle features per version. When they will be new.

@kthoms i think jreleaser is to much. Like mentioned above. Docusaurus has an version feature.

[sgort]

I will prepare a PR for this.

Concerning #1 are there still broken links?

[sgort]

Versioning images

By default, the npm run docusaurus docs:version command only snapshots the Markdown files (the /docs folder) and sidebars. It does not version the /static folder.
Since we've migrated the images to the /static folder, we need to move images to /docs/assets instead.

Solution

A follow-up PR will move assets to /docs/assets/ with relative paths to enable proper versioning support. I will create a "reverse migration" script based on the existing one used for #53

• Enable asset versioning support by moving images to /docs/assets/ first
• Add Docusaurus's docs:version functionalities