Here you'll find explanations of the core concepts and terminology of Scroll Versions.
Attributes are tags you can define and use to create conditional content (whether whole pages, or at a paragraph level) using the Variant management functionality in Scroll Versions. See Intro to Conditional Content and variants for more details.
The Author View is the normal interface Confluence authors see, as opposed to the Public View. For more information about the new elements Scroll Versions adds to the Author View, see Write content.
Scroll Versions saves each version of a page as a child page of the master page, with the same title prefixed with a dot and suffixed with the version name:
.<pagetitle> v<versionname>, e.g. .Glossary v3.0
Those pages are called dot-pages.
- Master page: Key Features
- Versioned page: .Key Features v1.0
When publishing within the same space, the content of those dot-pages will be copied to the Master page which is visible for the reader.
Inheritance and Fallbacks
Each version of a page is saved as a separate child page of the original. When you create a new version, it will inherit all the content of the preceding version you select for it. Once you edit a page, this fallback relationship is broken, and subsequent changes made to its preceding version will not be carried over.
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.
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.
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.
This feature allows authors to switch to a reader's perspective, showing them the currently-published content exactly as a reader sees it.
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 How can I change the versions of existing pages? 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.
Scroll Versions classes its users into three roles: Doc-Admins, Authors and Reviewers. See Roles and 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.
Exactly like the target space, when an action impacts a page, that page is called the target page.
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.
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".
A variant is a set of content defined by one or more attributes. See Intro to Conditional Content and variants for more details.
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.