Why Confluence's Page History Feature Doesn't Help When Managing Versioned Documentation

Why Confluence's Page History Feature Doesn't Help When Managing Versioned Documentation

When using Atlassian Confluence collaboratively to write and manage documentation, you will soon find that your content refers to multiple product/documentation versions within one or several spaces. Confluence’s built-in versioning functionality is a great way to track changes – but does it really help you manage multiple versions effectively?

And what does our Scroll Versions add-on bring to the table that default Confluence features cannot offer? Let’s find out.

Versions-Blogpost-Teaser.jpg

Confluences Page History Feature

As with all high-quality enterprise wikis, Confluence tracks the history of changes to each page.

You can access the history of a Confluence page from the Tools > Page History menu. On this page, you can compare versions, and restore or delete previous versions.

Confluence-page-history-revisions.jpeg

Atlassian describes entries in the  page history as ‘versions’. However, I personally feel the term ‘revisions’ would be more accurate, because changes always apply to the current page only.

Real Documentation Projects Need Real Versioning

In the real world, your product may have multiple versions – and as a result, so does your documentation. But Confluence’s built-in functionality doesn’t really help you manage entire page collections that refer to the same version of content.

For technical documentation, a version defines content that belongs to a specific documentation set or product release, such as:

  • Major software releases e.g. 1.0, 2.0

  • Minor product releases (1.1, 2.3.1)

  • Arbitrary release names e.g. “TP5” 

  • Or code names such as Apple’s “Mountain Lion”

To manage content that applies to specific versions, you would need to maintain it in separate Confluence spaces. Otherwise, you wouldn’t be able to modify a specific version’s content without affecting the content of other versions. But what happens if some content alters in a way that affects all versions of documentation – or a specific release and all subsequent versions? You’d need to copy the edited content manually – a tedious and inefficient exercise that often leads to errors.

Managing Versioned Content More Efficiently

What technical writers who manage versioned documentation in Confluence really need is a way to manage all versions in a single space, and a tool that lets them easily publish content that refers to a specific version.

K15t Software’s Scroll Versions add-on for Confluence does exactly that (and  much more besides). It allows technical writers to update content for later product releases, and to manage content that affects all or individual versions.

vsn_icon_txt.png

Concurrent versioning allows users to work behind the scenes on upcoming releases of their documentation. Once the product is released and the documentation is ready, they can  publish versioned content from the Confluence master space – the single source of truth.

Scroll Versions for Confluence

Our  Scroll Versions content management add-on allows documentation admins to  globally define specific versions for a Confluence space. And authors can choose a working version of a Confluence page, and edit is as required.

concurrent-working-versions-by-Scroll-Versions.jpeg

The Differences between Revisions and Versioning

Page revisions:

  • are created automatically when editing and saving a Confluence page.

  • refer to modifications on a single page.

  • are numbered automatically (revision 1, 2, 3 etc.).

  • can be compared with other revisions on the page history page.

  • are part of Confluence’s built-in functionality.

By contrast, versioned pages:

  • are created when an author edits a page in the desired working version.

  • refer to a specific version of content or your product – defined once for the entire space.

  • can be 

    compared to other versions

     of that page.

  • are available concurrently – each working version of a page can be edited separately.

  • are actually individual Confluence pages, each with their own revision history.

  • are only visible to a group of authors that has been defined by a documentation admin.

  • are possible in Confluence thanks to our 

    Scroll Versions

     content management add-on.

Conclusion

Revisions are a great way to track changes to a single page, and versions are crucial to managing content that applies to one or multiple releases of your documentation. Scroll Versions dovetails seamlessly with Confluence’s built-in page revisions feature. And it works both ways, as versioning enables users to track revisions, too.

Versions allow documentation experts – as well as us here at K15t and, most recently,  Atlassian technical writers – to manage multiple versions of documentation in a single space, and to keep track of versioned content with ease.

https://k15t.jira.com/wiki/plugins/servlet/confluence/placeholder/unknown-macro?name=www-blog-cta&locale=en_GB&version=2


Share this article
Sync Jira Without Apps
Sync Jira Without Apps

🧪 How would Sheldon Cooper collaborate on Jira? 🤔 He’d use Backbone Issue Sync’s remote license, of course!

Reset Cookies

The following services will be reset and deactivated for you.

  • Hyvor Talk:
    We're using Hyvor Talk as a comment tool. Hyvor Talk sets a local storage when activated. By clicking "Disable all services" you're no longer able to post or read comments on our website until accepting the service again.
  • YouTube:
    We're using YouTube to embed video into our website. YouTube sets cookies when activated. By clicking "Disable all services" you're no longer able to watch our embedded videos on the website until accepting the service again.

By clicking "Disable all services" all cookies and local storages related to the services will be removed. Before using them on our website again, you need to accept them.