Repository navigation
Versioning of the documentation #46
Description
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.
Activity
kthoms commentedon Nov 13, 2025
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 commentedon Nov 13, 2025
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 commentedon Nov 13, 2025
@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 commentedon Dec 21, 2025
I will prepare a PR for this.
Concerning #1 are there still broken links?
sgort commentedon Dec 21, 2025
Versioning images
By default, the
npm run docusaurus docs:versioncommand only snapshots the Markdown files (the/docsfolder) and sidebars. It does not version the/staticfolder.Since we've migrated the images to the
/staticfolder, we need to move images to/docs/assetsinstead.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/docs/assets/firstdocs:versionfunctionalities