Example: Building a software versioning model around Maintenance Branches

This example shows one way in which you can build a software versioning information model for IXIA Dynamic Release Management (DRM) using Maintenance Branches.

Organizing principle

In a software versioning model, once content is complete, it often needs to be maintained for the life of the product. But the content for a software version should not continue to change as new versions of the software are released.

A Maintenance Branch lets users update the content while keeping it separate from updates to other versions. Content in Maintenance Branch can be edited directly, but objects shared with a Maintenance Branch fork automatically when edited:
  • If they are edited within a Maintenance Branch, they automatically fork in the Maintenance Branch.
  • If they are edited in another type of Branch, they automatically fork in the other Branch.

Example workflow

The following is an example of how content is created and published using this information model:

  1. Create a Product or Library for all of the content and add a Release.
  2. Create Development Branches/Versions as needed, where users can work on content.

    One Development Branch is enough to start.

  3. Review and finalize content within the Development Branches.
  4. Once content is ready to publish, move the maps, topics, or other objects to the final status in their workflow.
  5. Generate output from the content in the Development Branches as needed for the initial software release.
  6. Add one Branch to the Release to act as the Maintenance Branch.

    As you release new versions of the software, you can add additional Maintenance Branches.

  7. Push the published content to a Maintenance Branch that is only for that software version.
  8. Edit the published content in the Maintenance Branch as needed to maintain it.

    Changes to objects in the Maintenance Branch will cause the objects to automatically fork from instances in the Development Branches. You can continue to make minor updates to the content and publish it without these changes carrying over to content for other software versions.

  9. Repeat steps 4 through 8 as needed for each new software version.