4  Versioning

Smallsite Design maintains versioning of articles.

In normal editing of an article in a word processing application like Word, there is no intrinsic support for identifying which version is a release, nor of hiding the intermediate versions created while getting to it, such as the drafts that are reviewed or the draft that is put up for final approval for release.

For simple articles for personal use, just repeatedly editing one version and then releasing it may be ok, but getting someone else to review it or getting it translated into several languages without managing versions may lead to a lot of confusion, especially if strict file naming conventions are not maintained. To alleviate such confusion, though at the expense of slightly more complexity, Smallsite Design maintains strict control over the process and the versions produced at each stage.

Keeping track of WIP versions is very important, though often overlooked in enterprises, as most documents will spend most of their lifecycle between releases as WIPs, which if lost would be a substantial loss of intellectual property. It would typically take at least half as much time again to recreate them as it took to write them, if all that had been done was actually remembered. Smallsite Design keeps each WIP file so that any content may be retrieved at any time up until a draft is produced at which time all WIPs leading up to it are deleted.

If wanting to keep some content that will not be going into the release, that WIP can be made into a draft. Except for the draft that is made into the release, all other drafts are kept, and must be manually deleted if not wanted.

To get to a release, the latest WIP is converted into a draft, then that draft is converted into a release. Technically, only the file name is changed, meaning that the release update timestamp is the timestamp of that latest WIP, not the time when made into the release.

While WIPs and drafts are not publicly viewable, they are available for private viewing for checking.

An article displayed on the Article body page renders a page close to how it will be when released, but using the fairly neutral colours of the management theme rather than its subsite's theme. In the Article body and History pages, any version can be viewed in another browser tab or window. This is to allow checking for how they are exactly rendered in the browser. Their URL can be copied for use in a different browser. To avoid confusion with the current release version, such viewing pages have a highlighted block with its status under the introduction.

However if a page is being viewed in this way when another is opened for viewing in another tab or window, it will remain until it times out, allowing comparisons of different edits.

Files are treated more comprehensively in Smallsite Design.

While Smallsite Design does not manage file versioning because it only stores the latest version, a file needs to be considered as a set of possible variants, each shown under different conditions. To elaborate, there will always be one for the master locale, which serves as the default, but a version can also be uploaded for the opposite reading direction or for each other locale. When not in the master locale, one of those other versions will be shown if it satisfies one of the conditions.

To make sure that the default version is shown in the master locale, the only allowed versions other than the default are for the opposite direction and non-master locales.

The typical use case for using different direction images is for when using a full-width banner image with a leading icon and text offset towards the end. The complementary directioned image would have the icon at the opposite end of the image with text offset in the other direction. This is so the icon is always leading the text for the current locale's reading direction.

Per locale versions would be required for scenarios like documenting user procedures for software, where the sample screenshots would need text in the language and script of the viewing locale.

Strict compliance requires that each version of an article specifies which particular version of each resource, like images, are used.

Smallsite Design has version management of the bodies of articles to help with the practicalities of editing and task-assignment. It is not a strictly-controlled configuration manager for legal purposes, so it is not suitable, on its own, for ISO9000-compliant records management, because the article always uses the current versions of its files. That is, the versioning of files is decoupled from the versioning of articles. Smallsite Design does not manage file versioning at all, and is only holding the latest version of each file.

However, Smallsite Design articles can be held in a records-compliant database by saving them from a browser as a single file, such as .mhtmlor .htm, which keeps all content, including linked and embedded files from the same site as one file, and then storing that file in the database. That Smallsite Design does not allow external files ensures that the file will be a complete archive of a page, except for those used by a Sequence element. A separate save of the page would be required for each locale.

They could also be saved as PDFs, but links and other active elements may be rendered as plain text or not shown, defeating the purpose of having a full record. For governments, where the configuration records are not allowed to be modified, this process is required for the items of many enterprise products like Atlassian's Jira and Confluence.

Articles are generally static, in that all information is visible and visibility is not controlled by checkboxes, unlike in the management pages. However, any Sequence element saved as part of an article to a single file will not function as its files are not saved. If wanting strict records version compliance and full working pages, avoid such elements.

Despite this, for almost all use cases used by Smallsite Design's target owners, such compliance is not required and would be unnecessarily onerous. However, that does not mean that backups should not be done, or archives not saved, as losing a site's content can very disheartening after having spent perhaps hundreds of hours building it up, let alone the financial hit taken if it is for a business. Archives are automatically created and selectively deleted according to an inbuilt schedule, but can be created on demand.