Documentation Versions

Each product in this portal documents one release at a time. The version selector in the header shows which release the manual you are reading describes, and lists the other releases that product has.

What each manual documents

Documented versions by product

Field	Type	Description	Notes
Business Plus Plus	3.0	Current. Earlier manuals for 2.5 and 2.0 exist but are not published in this deployment.	2.0 is out of support
FinGrow	2.0	Current. A 2.1 manual is in authoring.	1.8 archived
SuperMandi	1.4	Current.	1.2 archived
Project Four	1.0	Current. First release.

Documented versions by product

Note

A greyed-out entry in the version selector is a release this deployment does not publish. The entry is still listed, so the release history is visible, but it does not link anywhere — which is better than a link that 404s.

How versioning works here

Versions are declared per product in src/config/projects.ts:

src/config/projects.ts

versions: [
  { label: '3.0', path: '/bpp/', status: 'current' },
  { label: '2.5', status: 'archived', note: 'Archived — superseded by 3.0' },
  { label: '2.0', status: 'archived', note: 'Archived — end of support' },
],

An entry with a path navigates; an entry without one renders as an archived row with its note. That means the selector is honest about what exists without anyone having to maintain a second list.

Publishing real versioned documentation

The architecture supports three approaches. Which one fits depends on how different the releases are and how long you must keep them.

Path prefixFrozen deploymentsGit branches

Keep every version in the same build, under its own path segment. Content moves to src/content/docs/bpp/v3.0/…, and the version entries point at those paths:

versions: [
  { label: '3.0', path: '/bpp/v3.0/', status: 'current' },
  { label: '2.5', path: '/bpp/v2.5/', status: 'archived' },
],

Good for: two or three live versions where readers switch between them often.

Cost: build time and index size grow with every version retained, because all of them are rebuilt every time.

Build the current version only. When a release is superseded, deploy that build once to a permanent URL and point the version entry at it:

versions: [
  { label: '3.0', path: '/bpp/', status: 'current' },
  { label: '2.5', path: 'https://docs-v2-5.example.com/bpp/', status: 'archived' },
],

Good for: long archives, and for releases that will never be edited again.

Cost: search does not span versions — each deployment has its own index.

Keep one branch per release in the content repository and build each branch to its own target. The portal stays on main; release/3.0 and release/2.5 are built by separate CI jobs.

Good for: teams already managing product releases on branches, where a documentation fix often needs cherry-picking between versions.

Cost: the most CI to set up, and content fixes have to be applied per branch.

Important

Whichever you choose, keep the canonical URL on the current version and mark archived versions noindex. Otherwise search engines send readers to documentation for a release they are not running — the most common complaint about versioned documentation sites.

Changing the documented version

Update the product's version

In src/config/projects.ts, set version to the new release and add the previous one to versions with status: 'archived'.

Re-check the pages

The appliesTo field in each page’s frontmatter states which release the page was verified against. Update it as you verify each page, so readers can see what has been checked and what has not.

Rebuild

npm run build. The header, the footer, the page titles and the search index all pick up the new version from the config — there is nothing else to change.

Related documentation

• All productsBack to the portal home.
• Writing documentationHow to add and edit pages.