[Feature request]: Allow multiple versions

[tuxmea]

Use Case

With OpenVox 9 coming soon, we need to find a solution on having documentation for multiple versions.

Describe the solution you would like

Having the possibility to select the version on the website.
Versions differ between OpenVox, OpenFact and OpenBolt.

Describe alternatives you've considered

No response

Additional context

No response

[miharp]

Proposed approach for multi-version docs (#320) — looking for a gut-check before we build anything

With OpenVox 9 coming, here's the model I'd like to propose. It's deliberately simple and builds on how the site already works.

Versioned directories on one branch — no version branches

When a product cuts a new major, we copy its current docs into a new versioned directory and freeze the old one:

docs/_openvox_8x/   →   add docs/_openvox_9x/

master stays the single publishing branch. New work happens in the newest version; older versions only get deliberate backports for important fixes. This avoids long-lived release branches and the constant rebasing/backporting that comes with them.

Stable, per-product URLs with a per-product latest

/openvox/8.x/   /openvox/9.x/   /openvox/latest/
/openfact/5.x/                  /openfact/latest/
/openbolt/5.x/                  /openbolt/latest/

Each product versions independently — /openvox/latest/ could be 9.x while /openfact/latest/ is still 5.x.

Generated reference docs are pinned per version

So historical docs stay historical: OpenVox 8.x docs build from the OpenVox 8 source, 9.x from 9, etc. — rather than always regenerating from the newest tag.

A version selector in the UI

Probably at the top of the sidebar. It shows only the current product's versions and tries to keep you on the same page when you switch:

OpenVox:  latest | 9.x | 8.x

The ask

Does this general direction work for everyone? Specifically —

• Comfortable with directories-on-one-branch vs. release branches?
• OK treating each product's versioning independently?
• Anything about your product (OpenFact / OpenBolt / Server) that wouldn't fit this shape?

If the direction has support, I'll follow up with a concrete implementation plan.

[tuxmea]

I agree to the concept.
This is what we had from scratch and I am OK to continue that path.

At the moment cross section links use latest within paths.
We need to rename the affected links to stay at the same version.

General question: should we use versioned links instead of latest in general.

Another question which I brought to the monthly:

We have content unrelated to versions and we have the autogenerated content.
Some version unrelated content might change over time.
Should we link static content files instead of copying?

[tuxmea]

At the moment we filter prereleases. see https://github.com/OpenVoxProject/openvox-docs/blob/master/lib/puppet_references/repo.rb#L50 We need a different solution prior the first final 9.0.0 release is tagged