Create a branched fall-back path for software releases

Variants for Software Releases

Acme's requirements

From time to time Acme has to create a special build of their software to meet the requirements of a specific customer. When they create the branched build they also have to create a special build of the documentation - knowing that this content will not be published for the general release build.

Solution

"Branched" software releases use a fall-back path with additional nodes that modify the standard stepped structure. The topics for the branched release will not be included when publishing to the general releases, they will only be included when the branched release is selected in the publishing filter.

Branched nodes

Branched nodes are added as children of other releases. In this case the branched release is 1.1b which is added as a child of the 1.1 general release.

Branched Release Fall-back Path

Adding the branched node creates two separate fall-back paths - one for the branched release and one for the general release.

Requirements and behavior:

  • Create a new topic for the branched feature with the "release" variant criteria assigned for the "branched" build.
  • Other topics have the appropriate value assigned for the "general release" variant criteria.
  • When the book is filtered, the branched release topics follow the fall-back path from 1.1b to 1.1, and 1.1 to 1.0. That is, if there isn't a topic for 1.1b then Author will look for a topic tagged for release 1.1, then 1.0 if there is no 1.1 variant.
  • When the book is filtered for the general release, then the topics follow the fall-back path from 2.1 to 2.0, then 2.0 to 1.2, then 1.2 to 1.1, and 1.1 to 1.0. The path for 1.1b is not included.

Fall-back Paths