About Defects and Defect Actions For WIP Revisions

There is always a dynamic revision of a model version that represents the current work in progress (WIP). Existing defects can be targeted to be fixed in a WIP model version revision and new defects can be reported against the WIP model version revision. Freezing a WIP revision effectively creates a snapshot that represents a release that other model versions can use, with the appropriate defect or defect actions automatically linked to it.

See Also
Freezing a WIP Revision as a New Model Version Revision

In DesignSync terms, the WIP is the revision that represents the Branch:Latest version. For example, when working towards a release RelB of a model version, a revision can be created called RelB:Latest (in DesignSync) or simply RelB (in Defect Management and Collaboration). This revision can then be linked to the model version derivation structure at the end of the branch that it is on, so that it is seen as the Latest on the branch.

Any defect that is to be fixed in the RelB release would be targeted for that release by selecting the Commit for Model Version on the corresponding defect actions for the RelB:Latest revision. Similarly, any defect that is found during the development process would be created with defect model version Reported Against and Introduced In pointing to the RelB:Latest revision. This allows existing defects to be targeted to be fixed in a release that is in progress, and new defects to be reported against the release that is in progress.

At some point, the RelB:Latest revision becomes stable enough that it will be released. This could be either the final release or an intermediate or internal release. To do so, you must create a subsequent revision of the model version that becomes the new WIP revision. You need to ensure that any open defects that were reported against or introduced in the released revision are carried forward into the new WIP revision. All defect actions must be linked to the appropriate revision, either released or WIP, based on their current state when the new revision is created. In DesignSync, this is a mostly manual process. In Defect Management and Collaboration, the process is automated.

For example, in DesignSync, work has been progressing on the CPU model version using the WIP revision RelB:Latest. Defects have been targeted for that revision, and a number of those defects have been fixed and closed. Some new defects have also been found during development, and these defects have been reported against that revision. You are now at a point in the development process where you want to create an internal release, tagged as Gold. This internal release may be used by other model versions—for example, the CHIP model version has a CPU and wants to use the Gold version of CPU. The latest version of CPU on the RelB branch is 1.41. In DesignSync, the process for releasing this WIP revision is:

  1. Create a new revision 1.42 of CPU as the released version.
  2. Give this revision a tag of Gold.
  3. Link this revision to the derivation hierarchy between the version that RelB:Latest was derived from (CPU 1.41) and RelB:Latest. The CHIP model version can now make use of this new CPU revision.



Any defects that are reported against or introduced in revision RelB:Latest were found during the development of the release. If those defects have not been closed, then they still exist in the "released" CPU model version revision 1.42. All such defects (closed or not) must be relinked so that their Defect Reported Against Model Version or Introduced In fields point to revision 1.42.

Any defect actions that had RelB:Latest as their Committed Model Version revision are handled based on their current state:

  • Closed: These defect actions were actually fixed before the new WIP revision was created; therefore, they must be relinked to point their Committed Model Version to the "released" model version revision 1.42.
  • Rejected: These defect actions must be re-linked so that they stay with the "released" model version revision 1.42 against which they were rejected.
  • Test: These defect actions must be re-linked to the "released" model version revision 1.42 against which they were committed. They stay this way until they are closed, since the release is still being qualified. If a defect action is reopened, it must be manually linked to the current WIP revision.
  • Open: These defect actions are still under development. They must be relinked and remain open against the current WIP revision, RelB:Latest.
  • Evaluate: These defect actions were previously in the Open or later state and have been demoted back to Evaluate. They are not relinked to the "released" model version revision 1.42, and stay with the current WIP revision, RelB:Latest.

This entire process is automated in Defect Management and Collaboration. The Freeze Model Version menu option "freezes" the existing WIP model version revision, creates a new revision with a specified name, and automatically links the defects and defect actions to the appropriate model version revision. You can also specify a tag that should be associated with the new WIP model version revision to define its relationship to an existing model version hierarchy.