Version control is the process by which different drafts and versions of a document are managed. It provides an audit trail for the revision and update of these finalised 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 the main issues we had with our previous documentation solution was the lack of versioning capability. With agile, almost being the default mode of operation nowadays, most software companies prefer to release versions fast and often. The main post release activity is updating the documentation, this can be a tedious task and often forgotten.
Enter …… Document360
Version control is an important capability for documentation that undergoes lots of revisions and 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) 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 colours. (Red indicates content that has been removed; green shows the newly added content). It also offers different views such as Code Diff view, Rendered Diff view to view the differences.
In the example below, you can see how the difference viewer displays the differences between two article versions. You can also note that we are not comparing two adjacent versions, but two separate versions (Version 1 and Version 3).
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 there will be existing customers who 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 as “v1” and marked as the main version and made as a public version. In the 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 –
|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 just keep track of the different versions people are working with.
Take a look and let us know what you think.