Expanding the functionality of page versions, the Scroll Versions app introduces the concept of true space versions. A space version is a collection of pages that have been changed. So your team can manage all changes related to a release of your product, and keep them separate from changes for other releases. In Scroll Versions, you can manage space versions quickly without the complication that comes with writing documentation for major and minor releases of your product. So what would otherwise involve a manual process of space copying or exporting is instead done with the click of a button.
Within Scroll Versions you can define space versions for your content, which typically relate to a version of your product. When creating a space version, you set which version precedes the one you're creating. This is helpful for version branching, like for major and minor releases, and also for content inheritance.
With inheritance, changes in a version reflect on all subsequent versions. For example:
Let's say you have space version 1.0 for your first major release. You then create space version 2.0, which is based on version 1.0. With inheritance, any changes you make to 1.0 also appear in 2.0. This is particularly handy when making corrections or adding missing content. With inheritance, you don't have to copy the improvements to all future versions; it's just taken care of.
Now, there can be instances where you've updated something in space version 2.0 and then later in 1.0. In this case, the change in 1.0 will not be inherited in 2.0, to avoid overwriting the change in the newest version. This is useful when a part of your product is updated in every version. 1.0 is independent of 2.0. Even when going back and making a correction to space versions 1.0 should only affect that version, since space version 2.0 has been updated to reflect the latest version of the product.
As your team writes in your documentation space, you can schedule the version in which each page change is included. So maybe you made a correction that you want in space version 1.0 and maybe you've added a new section that should only be included in version 2.0. You can schedule these changes using a version picker right in the Confluence editor. You can also reschedule changes at any point.
With included reports, you can review changes to individual pages, compare the changes to a page across different versions, and see all changes included in a space version.
When you're ready to publish a version, you can provide it in a publishing space in a few different ways:
- If you want to provide multiple versions of your documentation to your customers, you can publish to a new publishing space each time you publish and name it after the given version.
- If you have a single space from which you always publish documentation, you can publish every version directly to that space. This updates all the content in the space to reflect the released version.
- To write and publish documentation in the same space, you can use roles and permissions to publish a released version so users can read it while your team works on other unreleased versions in the background.
Learn more about publishing.
When working with changes in your documentation, it's important to have the right people on your team review the content to ensure it's accurate. To help with this, Scroll Versions includes workflows, which automatically mark a page as a draft when you're updating it. You can then use workflows to move each updated page through the review process and then on for publishing.
For a more advanced review process, Scroll Versions also works with Comala Workflows.