Manage Versions

In this article, we'll compare the version management features of Scroll Versions with those of Scroll Documents. Specifically, we'll explore their differences in versioning, inheritance, and page hierarchy.

Versioning

Let's start with the basics of versioning. Both Scroll Versions and Scroll Documents offer ways to create and manage versions of your documentation. However, they approach this task in distinct ways.

With Scroll Versions, versions are called "space versions” – meaning any changes you make affect the entire space. When working in Confluence, you first create the version, and then make changes in a specific version of your content.

Scroll Documents offers a different approach. You can still define a “space version”, but it also enables you to define any Confluence page or page tree as a document. This means you can have multiple documents within the same space, each with its own versioning scheme. The versioning approach in Scroll Documents also follows a baselining approach, meaning you work on your content first, and at any given point you can save a version of that content.

Access versions

As soon as you create a version and/or a variant with Scroll Versions, a version and/or variant picker will be accessible in the Scroll navigation bar. In the Confluence page view, you can see how the page content changes to reflect the selected version and variant.

In Scroll Documents, the version and variant picker is located in the Document toolbox which redirects you to the selected version or variant of the page.

Additionally, Scroll Documents provides a Document Reader where you can switch between versions and variants when consuming content within Confluence.

If you want to share your versions and variants on a public website, you can do so with Scroll Viewport. To learn more, see: Publish Versions and Variants

Inheritance and Versioned pages

Let's explore the concepts of content inheritance and versioned pages.

In Scroll Versions, a page can be categorized as either:

• versioned or,

• unversioned.

A versioned page can appear the same or differ across various space versions. Initially, a versioned page inherits its content from the space version in which it was created. This inheritance persists until you modify or remove the page in a subsequent version. Once edited or removed, the page breaks its inheritance, and future versions derive their content state from the version the page was last edited or removed. In short, if you haven't made changes to a versioned page in a specific version, it continues to inherit content from the base version.

An unversioned page in Scroll Versions is essentially a standard Confluence page that doesn't belong to any particular version, maintaining a consistent appearance across all versions.

In Scroll Documents, the concepts of versioned and unversioned pages is not present. The app works with regular Confluence pages and introduces the concept of a "Working version." This is where you continuously work on your content. When you're ready to save your latest content as a new version, Scroll Documents copies all pages and saves them as the new version. From that point on, the new version stands on its own, independent of the Working version. Changes that you make in a specific version are not inherited into any other versions automatically.

Improve manual inheritance

While we’re not planning to introduce automated inheritance to Scroll Documents, we will make the process of changing content in multiple versions easier as a part of this improvement: DOCS-225

Page Hierarchy

Page hierarchy is another important aspect to consider. In Scroll Versions, versioned pages are stored as child pages of a "master page." Based on which version is selected, the corresponding pages are displayed. The arrangement of these master pages in the page tree determines the hierarchy for all versions. For this reason, it’s not possible to have different hierachies per version in Scroll Versions.

Scroll Documents is better integrated into Confluence itself and maintains the page hierarchy when you create a new version. This means that every version can have its own unique page hierarchy, offering flexibility in how your content is organized.

Conclusion

In summary, Scroll Versions and Scroll Documents each have their own approach to version management:

• Versioning:

  • Scroll Versions uses "space versions," which affect the entire space. Pages can be categorized as either versioned or unversioned. A version and/or variant picker is accessible in the Scroll navigation bar. Content differences in version and variants are reflected in the Confluence page view when the pickers are changed.

  • Scroll Documents enables "space versions" but introduces the flexibility of creating multiple documents within a single space, each with its own set of versions. Unlike Scroll Versions, Scroll Documents doesn't employ the concept of versioned or unversioned pages. Instead, it uses regular Confluence pages across different versions. The version and variant picker is located in the Document toolbox which redirects you to the selected version or variant of the page.

• Inheritance:

  • Scroll Versions inherits content from the base version.

  • Scroll Documents creates independent versions with copied pages.

• Page Hierarchy:

  • Scroll Versions only allows a single hierarchy across all versions.

  • Scroll Documents maintains page hierarchy in each version.