Version Management | Cirth Docs

Cirth supports multiple documentation versions, perfect for software with distinct releases. Readers can switch between versions while you maintain separate content for each.

Why Version Documentation?

Support multiple releases - v1.x users need v1.x docs
Preview upcoming features - Beta docs for early adopters
Archive old versions - Keep legacy docs accessible
Reduce confusion - Users see docs matching their version

Creating Versions

Your First Version

Every project starts with a Default version. This is your primary documentation that readers see first.

Adding a New Version

Go to Project Settings > Versions
Click New Version
Enter version details:
- Name: Display name (e.g., "v2.0", "Beta", "Legacy")
Click Create

Copying Existing Content

When creating a version, you can:

Start fresh - Empty version for new content
Copy from existing - Duplicate another version's pages

Version Settings

Default Version

The default version is shown when:

Users visit your docs without specifying a version
Search engines index your documentation
Links don't include a version parameter

To change the default:

Go to Versions tab
Click Set as Default on any version

Page History per Version

Each version maintains its own page history:

Changes in v1 don't affect v2
Restore points are version-specific
History is preserved when copying versions

Reader Experience

Version Selector

Readers see a version dropdown in the documentation header:

      
        plaintext
        
      
    Documentation    v2.0 ▼
                 ├── v2.0 (current)
                 ├── v1.5
                 └── v1.0 (legacy)

Version in URL

Versions can be accessed via URL parameter:

      
        plaintext
        
      
    docs.example.com/getting-started?version=v1.5

Sticky Selection

When a reader selects a version:

It persists across page navigation
Stored in browser for return visits

Managing Content Across Versions

Independent Pages

Each version has its own set of pages:

Page titles can differ between versions
Content is version-specific
Slugs are shared (same URL structure)

Common Patterns

Sequential Versions (1.0 → 2.0)

Create v2.0 by copying v1.0
Update pages for new features
Mark deprecated features
Set v2.0 as default when ready

Parallel Versions (Stable + Beta)

Keep "Stable" as default
Create "Beta" for upcoming features
When beta ships, copy to new stable version
Archive old stable as "Legacy"

Best Practices

Naming Conventions

Choose clear, consistent names:

Good	Avoid
v2.0	Version 2
v1.5.3	Latest
Beta	New
Legacy (v1.x)	Old

When to Create Versions

Create new versions for:

Major releases with breaking changes
New APIs or features
Significant UI/UX changes

Don't create versions for:

Minor bug fixes
Typo corrections
Small clarifications

Keeping Versions in Sync

For shared content across versions:

Identify common pages (e.g., "About", "Support")
Update all versions when these change
Consider linking to a single source

Deprecation Strategy

When retiring a version:

Add deprecation notice to all pages
Link to current version
Set a sunset date
Eventually archive or delete

Version Limits

Depending on your plan:

Plan	Max Versions
Free	2
Pro	10
Enterprise	Unlimited

Page History and Versions

How History Works

Each page in each version has independent history
Restoring doesn't affect other versions
Copying a version copies current state (not history)

Storage Optimization

Cirth uses delta compression:

Only changes are stored, not full copies
Base snapshots every 10 versions
~90% storage reduction vs full copies

Troubleshooting

Version Not Showing

Ensure version has published pages
Check version is not archived
Verify page status is "Published"

Wrong Version Displaying

Clear browser cache
Check URL parameters
Verify default version setting

Content Missing After Copy

Copying is instant - refresh the page
Check if pages are in "Draft" status
Verify copy completed successfully