Rules Using Implicit States

Instead of specifying a particular state in the normal lifecycle, you can choose one the following implicit states. These states do not apply to build stages.

Other rules are required in such cases, as each such title implies its own order-of-preference grouping. For details about other rules, see Rule Operation.

Implicit state | Grouping and order of preference
*All revisions (*ALL) | All revisions of each relevant item of the type specified, regardless of their lifecycle status, are selected for inclusion in a baseline specified using this template. This is for use with Dimensions Archive, Retrieval, and Transfer facilities (ART). If a baseline is made using a template which contains one or more rules with *ALL, such a baseline cannot be used for configuration build or release control purposes.
*Latest edit revision (*LATEST) | There is just one group, consisting of all revisions which are at any of the normal lifecycle states. It is equivalent to choosing the first normal lifecycle state specifically, with a LFS rule.
*Latest edit revision at final state in lifecycle (*FINAL) | There is just one group, consisting of revisions at the final normal lifecycle state only. It is equivalent to choosing that state specifically, with an EQS rule.
*Latest edited revision at the most progressed state (*HIGHEST) | The order of preference of the groups is: First, the group of revisions (if any) at the final normal lifecycle state. Then, the group of revisions at the next-to-final state. And so on downwards to the group at the first normal lifecycle state. It is equivalent to choosing that first state specifically, with a MPS rule. This implicit state is principally of value at an early stage in the development of a product, as it ensures that every relevant existing item (of the type that the rule is concerned with) gets selected at the latest revision of its most progressed status.
*Revision built from selected inputs (*BUILT) | The selection procedure used here is entirely different from that for other implicit states. Regardless of the order in which they were specified, rules with implicit states *BUILT and *MADE OF are interpreted after all other rules have been used to select item revisions of other types. All relevant items of the types specified in *BUILT rules are reviewed for potential inclusion in the baseline, and each relevant item is inspected individually as follows. The lifecycle status of the relevant item's revisions is not significant in this case, but each of the revisions is considered in turn, to see if one can be found which has been built, using as inputs some of the item revisions already included in the baseline. For such a revision to qualify, it must have been the output of a Dimensions build process, and all the inputs used in that process must be found, either already included in the baseline (as a result of processing the template rules of other types (rules other than *BUILT), or included in the baseline as a result of earlier processing by this *BUILT procedure. NOTE It does not matter in which order *BUILT rules are specified because this *BUILT processing is reiterative: the whole cycle will be repeated as often as necessary on all the relevant items of types in *BUILT rules, until all possible orders and combinations have been dealt with. If such a revision can be found to qualify, then this revision is also included in the baseline, and the item is considered to have been successfully selected. However, if each of the item's revisions has been considered, and none has been found to meet these criteria (and further iterations of the entire cycle could not improve on this), a warning message is issued to say that this item has not been included in the baseline. And the inspection process starts over again on the revisions of the next relevant item.
*Revision that makes selected outputs (*MADE OF) | This selection procedure uses an inverse criterion to that used for *BUILT. In *MADE OF rules also, the lifecycle status of relevant item revisions of the types specified is not significant in selecting them for inclusion in the baseline. In *MADE OF rules the selection is made by examining the made-of lists of built item revisions which either are already in the baseline or have been included in it as a result of previous iterations of this *MADE OF processing. Wherever such a made-of list contains any item revision which is of the types specified in *MADE OF rules, as well as being a relevant item (within the scope of the baseline), then that item revision is also included in the baseline, provided that no other made-of list so examined contains a different revision of the same item. If such a conflict of revisions arises, no revision of that item is included in the baseline, and an error message is issued to explain this.

For details about the *BUILT and *MADE OF rules, see Using *BUILT and *MADE OF Implicit States.

Related Topics

Illustration of Rule Operation

Default Rule and Other Uses of Implicit States