feat: support for multi version docs

[anishbista60]

Docs Versioning Workflow

Day-to-day (no release needed)

Every PR merged to main triggers .github/workflows/deploy-docs.yml, which runs:

mike deploy --push --update-aliases dev

This rebuilds and pushes the dev version to the gh-pages branch, live at docs.kubevirtbmc.io/dev/.

✅ This is what unblocks you — merge freely, no release needed.

Cutting a docs release ("stable")

When you want the public/default docs to reflect a new KubeVirtBMC release:

1. Make sure main has the docs content you want to snapshot (already merged via normal PRs).
2. Tag it, matching the release version:

   git tag v0.9.0
   git push origin v0.9.0
   

3. Pushing that tag triggers the same workflow, but the tag-matching step runs instead:

   mike deploy --push --update-aliases v0.9.0 stable
   mike set-default --push stable
   

   This builds a new version named v0.9.0, aliases it stable, pushes it to gh-pages, and sets it as the default (root /) version.

Result: docs.kubevirtbmc.io/ (and /stable/) serves v0.9.0, while docs.kubevirtbmc.io/dev/ keeps rolling forward with whatever's merged to main next. Old version snapshots (v0.8.1, etc.) stay published too — mike never deletes prior versions unless you run mike delete.

⚠️ One-time setup still needed before this works in production

GitHub Pages for kubevirtbmc/docs is presumably configured to deploy via the Actions artifact method (deploy-pages/upload-pages-artifact), which we removed. Since mike pushes content directly to the gh-pages branch instead, someone with admin rights on the repo needs to change:

Settings → Pages → Build and deployment → Source → "Deploy from a branch" → branch gh-pages, folder / (root)

Until that's changed, the workflow will push commits to gh-pages successfully, but GitHub Pages won't serve them.

[anishbista60]

[starbops]

Does this mean we'd need to create a new tag in kubevirtbmc/docs? I was hoping we could avoid that release overhead. Instead, I'd prefer the documentation site to serve versioned docs from long-lived branches, with one branch per minor release. That said, if Zensical doesn't make this easy to implement, I'm fine with sticking to the current approach.

[anishbista60]

Does this mean we'd need to create a new tag in kubevirtbmc/docs? I was hoping we could avoid that release overhead. Instead, I'd prefer the documentation site to serve versioned docs from long-lived branches, with one branch per minor release. That said, if Zensical doesn't make this easy to implement, I'm fine with sticking to the current approach.

Yes, we need to create new tag.

But I think long-lived branches approach reduces burden. Let me explore that part and get back here.

Thanks