Version control is the process by which different drafts and versions of a document are managed. It provides an audit trail for revising and updating these finalized versions.
We are starting this Feature Spotlight series to give you a better idea of our capabilities. Document360 was designed and developed based on our 5+ years of pain points building documentation for our successful enterprise products BizTalk360, Atomic Scope & Serverless360.
One of our main issues with our previous documentation solution was the lack of versioning capability. With agile, almost the default mode of operation nowadays, most software companies prefer to release versions quickly and often. The main post-release activity is updating the documentation, this can be a tedious task and often forgotten.
An intuitive knowledge base software to easily add your content and integrate it with any application. Give Document360 a try!
GET STARTEDArticle Level Versioning (Revisions)
Version control is an important capability for documentation that undergoes many revisions, especially when multiple users are working on the same document. The articles are prone to human error and versioning helps to bring back / recover the document to a healthy state. The challenge is to compare the two versions and find out the differences.
To (edit an article) or create a version of an existing article, you need to fork the already published article.
When you fork the published version, this will automatically create a second version (Version 2) of the same article. In this situation, the current version will be v2 and the published version will be v1.
Once you publish the edited version of the article, the published version will change to v2.
Document360 also has a rich difference viewer capability that displays the older version content on the left and the newer version on the right. The differences will be highlighted in red and green colors. (Red indicates content that has been removed; green shows the newly added content). It also offers different views such as Code Diff and Rendered Diff to view the differences.
The example below shows how the difference viewer displays the differences between the two article versions. You can also note that we are not comparing two adjacent versions but two separate ones (Version 1 and 3).
Project Level Versioning
As an example, Say the current version of the product is, say, v1.0 and in the next release, a major revamp is done to the UI, and new features are added to the product. Since the UI change is throughout the entire project, most of the screenshots in the product documentation will change.
In this case, it is not apt to change the v1.0 documentation since existing customers will be using v1.0 of the product. The ideal thing to do would be to create a new version of the documentation (say, v2.0) and work on the changes for the new product version.
By default, when a project is created in Document360, the version is numbered “v1” marked as the main version and made as a public version. In Settings ->Versions you have the option to create a new version and provide a friendly name for it.
You need to specify which will be the base version that you will be forking (making a copy of)
Once a project is created, you will notice that there are different configuration options available such as –
Configuration | Description |
Main Version | Set the newly created version as the main version |
Is Beta | Enable this option if your documentation is specific to a beta release |
Is Public | Enable this option if your documentation should be publicly viewable by your customers |
Is Deprecated | Enable this option to mark your documentation as deprecated (specific to any old version of the product that is no longer supported) |
Thus, with Document360, you can easily update all your documentation with new features and screenshots after a release (maintaining a different version) or keep track of the different versions people are working with.