Glossary

Here you'll find explanations of the core concepts and terminology of Scroll Versions.

Attributes

Attributes can be assigned to pages or conditional content macros and are the basis of variant definition. See Intro to Conditional Content and Variants for more details.

Author View 

The Author View is the normal interface Confluence authors see. For more information about the new elements Scroll Versions adds to the Author View, see Navigate the App.

Change page 

Scroll Versions stores versioned content of a page within prefixed child pages of the master page, which is the page visible to the user. Their names are constructed as follows: .<pagetitle> v<versionname>, e.g.  .Glossary v3.0

Those pages are called dot pages because of the leading dot. They are only created for a version if the content was edited in that version, which is why they are also referred to as Change pages.

Usually those pages aren't visible to users, but they can be seen within the Reorder pages dialog:

If no change page is present in a version, the content is inherited from the previous version, which is referred to as a fallback.

Inheritance

In Scroll Versions, later versions that are on a version tree inherit content from the earlier versions. Content inheritance works on the page level and is stopped for a given page in a given version once it gets edited in that version. You can see the current inheritance status in the Page Byline.

Example: If your space has 5 versions and a page was created in version 1 and hasn't been edited in any versions since, versions 2-5 will be inheriting the content from version 1 and are so-called fallback pages. If you now edit the page in version 3, this will break the inheritance between version 2 and 3. Version 3 will store its content in its own change page, while the versions 4 and 5 will now inherit content from version 3.

Editing page content that is being inherited by succeeding versions changes those versions.

Fallback page 

Fallback pages are "missing" pages in a version that fall back to the previous version for their content.

Every page in a version is either a change page or a fallback page.

Master page 

Scroll Versions saves page versions as child pages of the original, which are not displayed in the page tree, but can still be accessed (for example, through View in hierarchy). These pages should not be edited. Everything should be done through the root page, called the master page, which is always the most recent version. You can restrict editing of master pages. See Link to Pages in a Versioned Space for more details.

Master space

When you author and manage all your versions within a single space and publish to a separate publicly-available space, the space you actually work in is called the master space.

Preceding version

Versions created with Scroll Versions are created on the space level, allowing you to manage multiple versions concurrently in a single space. All changes to pages in a space are associated with the selected working version. When you create a new version, it inherits all content from the preceding version. This is called inheritance. New versioned pages will only be created if you edit a page in that version.

Public View 

This feature allows authors to switch to a reader's perspective, showing them the currently-published content exactly as a reader sees it.

The Public View only makes sense if you publish a version within the same space, which is a feature we no longer recommend to use.

If you publish to a new, existing or even remote space, you have to open the target space to see what your readers are actually seeing.

Rescheduling

With the reschedule feature available via the Scroll Versions Dropdown > Reschedule, you can reschedule a page version to another page version. This comes handy if, for example, you've documented a specific feature for version 2.2 which will be shipped in 2.1 instead; you can reschedule the page to version 2.1. See Change the Version of a Page for more information.

Revisions in a page's history

Confluence tracks the history of changes to each page by creating a new version of the page each time it's modified. You can compare page revisions to view changes, rollback to a previous version if you need to, and delete specific page revisions. All of this is handled on a page-specific basis only. Scroll Versions enables space-wide versioning.

Roles

With Scroll Versions 4.5.0 Scroll Roles are hidden per default and need to be activated manually.

Scroll Versions classes its users into three roles: Doc-Admins, Authors and Reviewers. See Permissions for more details on the three roles and what actions they can perform.

Scroll Page ID

All pages in a space managed with Scroll Versions have a Scroll Page ID. The Scroll Page ID is an internal ID saved as content property by Scroll Versions. This ID is used to map versioned pages. When it comes to publishing, the Scroll Page ID is used to map the pages and update the content accordingly.

Target page

Exactly like the target space, when an action impacts a page, that page is called the target page.

Target space

When performing an action that involves two spaces (such as publishing a version), the space on the receiving end of that action (such as the space that will be published to) is called the target space. 

Scroll Versions should not be active in the target space, as it's currently not possible to publish to a space where Versions is active. See VSN-2054

Unversioned pages 

Unversioned pages are, essentially, normal Confluence pages. They appear (and remain unchanged) in all versions. In general, all pages should be versioned. Using unversioned pages is useful for certain exceptions, such as a glossary, legal imprints etc. If you activate Versions in a space, all existing pages are unversioned until you edit the page (thereby creating a version of the page). If you're using the Workflow Management functionality, unversioned pages do not have a workflow status and are always treated as "complete". 

Variants

A variant is a set of content defined by one or more attributes. See Intro to Conditional Content and Variants for more details.

Versioning

As your product evolves, your documentation does, too. In a technical documentation context, a version defines content that is associated with a specific documentation set or product release. There are two ways to version your content in Confluence: using Confluence's built-in page revisions functionality, or concurrent versioning of content within a space using Scroll Versions.