Versioning is the practice of recording distinct states of something over time, with enough information to tell them apart, compare them and return to one if needed. A good version record links each state to a date, an author and a reason for the change.
Three kinds of version are often confused. Version history is the automatic record a developer, CMS or editor keeps of every save. It’s useful for recovery but noisy. Published versions are the states users or readers saw, each with the date it went live and, where it matters, who approved it. Named releases are deliberate, labelled states, sometimes maintained side by side, such as documentation for version 2 and version 3 of a product, or a guide marked 2.1 while work continues on 2.2. Software often numbers releases using semantic versioning, where the number signals how significant the change is.
Why it matters for content
Versioning supports collaboration and accountability. Editors can review differences rather than reread everything, and teams can trace when a claim changed and who approved it. An editor checking a changed eligibility rule needs to know which text was published, which is under review and what changed between them.
A retained earlier state can support recovery after an error. Check that it’s still suitable and compatible with current systems, because version history alone doesn’t make restoration safe.
Some old versions should stay public. Customers on an older product need documentation that matches what they’re using, so many documentation sites keep several releases available with a version switcher. Terms and conditions, privacy notices and policies may need earlier versions available because people agreed to them or decisions were made under them. Archived versions should be clearly labelled, kept out of search results where possible and linked to the current one. Each maintained version adds work, so retire versions once nobody relies on them.
Versioning needs conventions: what creates a new version, which one is current, how versions are named and how long history is kept. Record enough context to explain a consequential change, not only its timestamp. A changelog does this for readers, summarising notable changes in plain language rather than listing every edit.
How AI changes the picture
AI can compare versions, summarise changes and flag possible regressions. It can help reviewers focus on altered meaning and dependencies.
Version the instructions, retrieval sources and configuration that an evaluation depends on. Record the exact state tested, including a model version where the provider exposes it. Some services change without offering a reproducible snapshot.
Generated content also needs provenance, so teams know which source, instruction and review produced the published state.
Questions people ask
- Does a CMS revision history count as versioning?
Partly. It records every save, which helps with recovery, but it rarely shows which state readers saw, who approved it or why it changed. That takes labels, approval records and release notes on top.
- What is the current version?
The published or approved state, and it should be marked as such. A document labelled “current” in an editing folder may be the next draft, not the version readers are using.
- Should every tiny edit create a version?
Keep automatic edit history where useful, but label releases that readers or maintainers need to tell apart. A typo correction may not need a new release number. A changed policy may need a clearly identified state.
- Can versions be deleted?
Retention depends on legal, operational and historical needs. Whatever is kept, people using the content shouldn’t mistake an archived version for the current one.
Learn more
- Documentation versioning in Docusaurus – a concrete guide to released documentation snapshots and an evolving current version, including the added complexity and reasons to limit maintained versions.
- Semantic Versioning 2.0.0 – the widely used convention for numbering releases so the number signals whether a change is a fix, an addition or a breaking change.
- Keep a Changelog – a short convention for writing changelogs for people rather than machines, with an entry for every version and the latest first.