How to Document Systems with Different Versions?
Scenario
I need to create and maintain a user documentation for a system of which there are different instances in use by different target groups. There are several levels of integration with other systems, several development stages, several regional production deployments. Not all of these instances have the same feature set (e.g. some features are just for tests, some features might be regionally limited et cetera).
Additionally the system consists of single services that may or may not be deployed together which affects the feature characteristic of the overall system as well.
Challenge
Finding a system that helps any user with one documentation with feasible effort. Currently the approach is to always document the latest development iteration in a versioned wiki system and indicate functionalities that are "just" testing functionalities. Is there a better way to document such fluid systems?
(4)4 Comments
Sorted by latest first Latest Oldest Best
What kind of software do you use for content development? I've found that branching is a good way to address version control if you have a need to support multiple versions simultaneously, but you would need a Content Management System (CMS) or authoring tool that has this type of functionality. You also need to consider how the information is delivered and whether that system has the functionality you need.
With branching, you can create, edit, and manage different versions of content in parallel. For example, you might edit the current version, let's call it 1.0, in a master branch. Once you've released your content for v 1.0 you would branch that content. This basically involves making an exact copy of the publication. Then, you can edit in the master branch to develop content for v 1.1, while still maintaining v 1.0 separately. You can also publish each version to provide accurate support to your end users for those versions.
Additionally, if you have a need to publish different content for different audiences, you might consider using conditional processing. For example, if you need to publish certain content on "testing" features for an internal audience only, you could tag those features "internal" or "testing" and filter the published content accordingly to include or
not include that content. Similarly, you could conditionalize content for integrations, specific audiences, etc.
I work in a DITA CMS that has all these functionalities, so again, you would need to have a system or systems that can support these functions.
Paligo has an integrated DocBook CMS with branching, profiling, and various reuse features that make it relatively easy to create and maintain multiple versions of the same documentation. I branch a publication (collection of topics) after each release (1.1, 1.2, etc.). Then I branch individual topics in the new branch to reflect changes in that release. I can also edit an unbranched topic to make corrections in all the releases that share the topic.
You can use the same features to create docs for multiple variations of an individual release.
I migrated from Confluence using Scroll DocBook Exporter and with help from Paligo tech support (included in the subscription) it was pretty smooth as such things go. Any future customer doing the same would probably benefit from a lot of lessons Paligo learned from my experience.
I think it's cost-effective for documentation groups that are too small to justify the cost of building a system around a DITA CMS. You might want to look at Author-it Cloud and MadCap Central as well.
I use madcap flare, and using condition tags allows you to produce 2 versions from the same content.
The method Splunk uses for their documentation is to use a per-version structure (though oftentimes the doc is the same for two different versions of the tool), and allow the reader to pick which version they want to read.
So you might be looking at 7.0.2, or 6.5.1, or 6.2.3, or any other possible version.
The URLs look like the following:
docs.splunk.com/Documentation/Splunk/7.0.2/Knowledge/Configurecalculatedfieldswithprops.conf http://docs.splunk.com/Documentation/Splunk/6.5.1/Knowledge/Configurecalculatedfieldswithprops.conf docs.splunk.com/Documentation/Splunk/6.2.3/Knowledge/Configurecalculatedfieldswithprops.conf
While I don't know what powers their system under the hood, I do know the doc team publishes docs for new versions when new versions release. And that old versions' docs are kept around more-or-less forever.
Terms of Use Privacy policy Contact About Cancellation policy © freshhoot.com2025 All Rights reserved.