Each time content is released (both major and minor), an exact copy of that version (with all its topics and other resources), called snapshot, is saved and archived.

When the state of a publication or topic is set to Released in Paligo, an archived version of the content at that particular point in time called snapshot, is automatically created. It is possible to add a comment that provides more context about the snapshot for other users. A snapshot can also be created during a review assignment.

A snapshot is useful when you compare different revisions or need to restore an old version of a publication or a topic.

The snapshot is a ZIP file consisting of several XML files (the topic, translations and variables) and images. When a version is restored, that file is imported back into Paligo and treated like new content, which results in topics and fragments getting new IDs. The restored version is independent in regards of the original content. Because the restored release may have had completely different variables and the like, such resources will be separate and possibly partially duplicated. You may therefore want to clean such resources up after republishing your old version.

There is no limit to how many versions Paligo stores. Restoring an old version does not affect other archived versions and does not remove earlier versions. Archived releases (whether restored or not) use up your storage space. If you know that you do not need old versions, you should remove them.

Once a topic or publication is released, an archived version of it called a snapshot is saved. To be able to edit a released topic or publication, you need to create a new version, by changing the status back to Work in progress. This will not affect the archived version.

When you open a topic used in a released publication, it will be in status Released. You can make a new version of it by changing the status in Resource View, but you do not have to, when you open it in the editor, you get the option to change the status back to Work in progress.

Should the publication (or other components where the topic is reused) not already be in Work in progress, Paligo will allow you to change the status of them as well.

The topics that do not require change in the new version can (and will by default) remain in Released status.

A snapshot is an archived version of the content at a particular point in time. During a release, a snapshot is always created, but can also be created by a contributor during an assignment in Contributor Editor or manually created at any time in Resource View. To be able to create a snapshot in Resource View, you have to be an author or administrator, see User Types.

The snapshots are useful when comparing the content between different versions or for restoring lost content. Comparing a snapshot from before and after an assignment makes it easy to visualize the changes made to the documentation. To learn more, see Timeline.

Administrators, authors and contributors can create content snapshots. A snapshot is an archived version of the content at a particular point in time and is useful when you compare different versions.

When a snapshot is created, you can add information about why the snapshot was created (for example feature changes, feedback comments or contributions). This information is visible in Resource View.

If you think about the fact that one of the main purposes of Paligo is to reuse content, what does it mean to change the workflow or release status of a piece of content?

Obviously, because topics are reused, if you change the status of one document, it will have an effect on others as well. This can easily get very complex if you need to keep track of it yourself. Paligo does it for you by default though, but it's good to know how the default mechanisms work.

Whenever you change the workflow status of a document, there is a choice whether that should affect any documents related to it.

Status Change Checkbox

The checkbox in the menu for changing the workflow status gives you a choice whether any included topics should also have their status changed. This is sometimes called changing the status recursively.

The checkbox has different default values, depending on what the current workflow status is for the component you are changing:

Table 2. Default values for changing status recursively

Current workflow stage	Default checkbox value
Released	Not checked: The change will by default only affect the one you are making the change on. For example, if you change a publication from Released to Work in progress, only the publication itself will change, not its topics. Logic: Just because you are changing e.g a publication from Released to Work in progress, most of the topics may not need to change, and will therefore remain released.
Any stage except released	Checked: The change will by default affect all components reused by the one being changed. For example, if you change a publication from Work in progress to Released, then all the topics used in it will also be released. Logic: If you are changing any component that is not released, e.g to Released, then normally this would mean that all included topics are also released.

You can of course change the default with the checkbox, but the default values are usually recommended.

Tip

If you change a released publication to Work in progress, you do not have to manually change the status of each topic you are going to work on. Paligo will give you the option to change its status whenever you try to open a released topic. This makes it clear what topics have actually changed during the workflow cycle.

How Changes Affect Other Components

The status change checkbox determines what happens to components reused in the one you are changing. But what about topics and other publications that are related?

For instance, if you release one publication, and all its topics, what happens to another publication where some of the same topics are reused?

There are many scenarios, but the ones below may help understanding the most important effects:

Figure 1. Work in progress → Released (changing the publication status)

If we change Publication A from Work in progress to Released, all its topics will by default also be released. This means that the sub set of topics reused also in Publication B will of course also be released.

The component Publication B in itself will not be affected.

Figure 2. Released → Work in progress (changing the publication status)

If we change Publication A from to Released to Work in progress, only the publication component itself will change. This means in this scenario, Publication B will not be affected at all, neither its topics nor the component itself.

Figure 3. Released → Work in progress (changing the topic status)

If we change Topic A from to Released to Work in progress, we will also by default change the publication it is reused in. Since it is reused in both Publication A and Publication B, both of these publication components will change to Work in progress.

You can override this behaviour if you want, using the checkbox in the dialog, but it is normally not recommended. If you are changing Topic A, you are of course effectively working on a new version for any component where it is reused.

There can of course be exceptions for pragmatic reasons. If you have reused Topic A in 100 publications, and you need to make a minor change, and the publications do not need to be republished. Or the change is filtered only for Publication A. Then it's completely up to you to override the default, using the checkbox.

These are some of the common scenarios, but of course there are others. As mentioned, if the default behaviour fits you well, you rarely need to think about it, as it all happens automatically.

But you are encouraged to try various scenarios out on sample content if you want to learn more.