Define selection criteria for baseline or release templates
Add or update the selection criteria for a baseline or release template to specify which items to include in a baseline or release.
Add selection criteria for a template
To add or modify the selection criteria for a baseline or release template, you need the Manage Baseline and Release Templates privilege.
To define the selection criteria:
In the Administration Console, go to Product Administration > Baseline & release templates.
In the navigation pane, select the baseline or release template for which you want to define the selection criteria. The template details are displayed in the content pane.
To add a selection criterion, click the New criteria button in the Selection Criteria section. The Add Selection Criterion dialog box opens.
To edit an existing selection criterion, in the Selection Criteria section, select the criterion and click the Edit criteria button. The Edit Selection Criterion dialog box opens.
For item baseline templates, specify the following details:
Select the item type to which the criterion applies.
An asterisk (*) means that the criterion applies as the default for all item types with no specific criterion defined.
Associated Lifecycle The name of the lifecycle that has been associated with the item type.
Specify the lifecycle state or build stage to which the criteria applies. Select an actual state or one of the implicit values.
For a list of the implicit states, see Selection criteria for item baseline templates.
If you select a specific lifecycle state or build stage in the Lifecycle State field, select an option from the State Selector list:
If your Lifecycle State is an actual state, select a Status Related option.
If your Lifecycle State is a build stage, select a Stage Related option.
If your Lifecycle State is an implicit state (one beginning with an asterisk), select <none>.
For details, see Selection criteria for item baseline templates.
For request baseline templates, specify the following details:
Field Description Request Type Select the request type for which this criterion applies. Request Status Select the lifecycle state of requests to be used in the selection criteria.
Baseline Status Code
Select the rule that applies to the selected Request Status:
Select SUP to include requests at the specified state and upward.
Select EQS to include requests only at the specified state.
For details, see Selection criteria for request baseline templates.
For release templates, specify the following details:
Select the highest-level design part to which the criterion applies.
The criterion applies to all the subordinate parts, unless overridden by a more specific criterion.
An asterisk (*) means that the criterion applies as the default for all design parts for which no specific item type criteria exist.
Enter the required variant to limit the criterion to one variant of the selected design parts (plus subordinate design part variants).
An asterisk (*) means that all variants of the design part apply.
Select the item type or item type group for which the selection applies.
An asterisk (*) means that all items are subjected to the criterion.
Enter a hyphen (-) if you do not want to include any items.
(Optional) Specify the name of a subfolder for the item types selected by the criterion. Use up to 50 characters.
The subfolder is added to the release folder pathname specified by users when they make a release.
The subfolder must be a relative format (such as xxx/yyy for UNIX or xxx\yyy for Windows.
For details, see Selection criteria for release templates.
To delete a criterion, select the criterion in the Selection Criteria section, click the Delete criteria button, and confirm.
In an item baseline template, you specify selection criteria for the item types to include in a baseline.
An item baseline template consists of a default criterion for all item types, and selection criteria for specific item types that override the default for those item types for which they have been defined. The baseline template thus consists of a list, or set of these criteria that determine which item revisions to include.
Selection criteria can be defined either as implicit or for a specific normal state or build stage in the lifecycle.
Options for implicit states:
Latest edit revision.
Note: Latest edit revision in this context means the last item revision that was created.
Latest edit revision at Final State in Lifecycle.
Latest edited revision at the most progressed state.
Revision built from selected inputs.
Revision that makes selected outputs.
If you select one of these implicit states as the Lifecycle State, you do not require any additional rules. The implicit state is sufficient to determine which item revisions to include. You can leave empty the State Selector field.
If you specify a particular lifecycle state as the Lifecycle State, you need to provide an additional status rule in the State Selector field.
Options for an additional status rule:
Latest from state.
Most progressed state above specified state OR specified state.
Specified state OR most progressed state.
Specified state OR next existing state upward.
Specified state only.
If you specify a particular build stage as the Lifecycle State, an additional stage-related rule need to be provided in the State Selector field.
Options for an additional build stage rule:
Specified build stage and all next existing build stages upward
Specified build stage only.
Dimensions CM uses these additional rules together with a selected normal lifecycle state or build stage to determine a grouping and order of preference for the item revisions to be included in baselines using this template.
For details about using rules, see Rule operation.
In a request baseline templates, you specify rules for selecting Dimensions CM requests that are used as input for creating a baseline from their related items.
The rules are made up from the following:
Baseline status code, which itself comprises one of the following keys:
EQS (specified state only).
SUP (specified state and upward).
When a baseline is created specifying a request baseline template and a set of starting parent requests, all the requests that are related to those parent requests and match the template rules are collected together for processing.
The template rules are processed in the same way they are for item templates. Requests are selected based on the type, status, and the baseline status code that was specified.
Example: If a template has a rule that specifies all requests of type PR, at status ACCEPTED, and with the baseline status code EQS, then all the requests of type PR, at the status ACCEPTED only are included into the baseline.
After this list of requests has been determined, only the items related to those requests as In Response To or, optionally, Info are included in the baseline. Because the baseline that is being created is a release baseline, only one revision of each item is included in the baseline (not all revisions, as in a design baseline). This means that even though the selected requests may contain multiple revisions of the same item, the final baseline includes only one revision of all these possible items.
To ensure that only one revision of an item is included in the final baseline in circumstances where multiple item revisions are related to requests, only the latest item revision is selected using that item's pedigree.
When the baseline has been created, the requests used to create it are related as In Response To that new baseline.
To enforce a consistent model with its behavior for items only, the following additional constraints apply to creating a baseline with respect to cited requests:
Requests that are either at a closed or off-norm lifecycle state are be processed by the SUP baseline code.
Only requests in the primary catalog are processed.
Only requests related through a dependency relationship, that is, DEPEND, are included in traversal scans.
If a request related through a dependency relationship does not fulfill the criteria specified in the request template rules, then that request and any of its child requests are ignored. This means that for a situation where N levels of requests are related together in a chain through dependent relationships, for example, CR_1 > CR_5 > CR_7 > CR_9 > CR_12, if CR_7 fails to match a template rule, then it, together with CR_9 and CR_12, is ignored in any further processing.
Only requests owned by the product where the baseline is being created are processed. Requests owned by other products are ignored, including children of such requests.
Only parts or items that are owned or have usage relationships to the parent part specified when the baseline is created are included in the final baseline. This means that if a request refers to affected parts and/or items that may be out of scope (not owned by or related to the parent part or any of its children), then these parts and items are ignored.
A release template may consist of any number of selection criteria, where each criterion defines the following:
(Optional) Specifies a design part. This rule is then applied to that design part and to any part subordinate to it in the design part structure tree, unless and until another criterion specifies a subordinate design part, in which case that other rule overrides for that subtree, and so on. Alternatively, a criterion may be applied to all design parts of the product.
Specifies one or all item types, or a group of item types identified by an item type group you can create for this purpose.
(Optional) Specifies a subfolder of the release folder. The items of all types specified by the criterion, for all design parts selected by the criterion, are placed in the specified subfolder, or otherwise in the main release folder.
Release template subfolders
Subfolders simplify subsequent handling of the release data. For example, you can specify that executable code, source-code modules, user documentation, and system-specification documents are each to be grouped in different subfolders. This field defines a subfolder to be added to the release folder pathname specified by users when they make a release.
If a release template is specified, the items are placed in the subfolder, as specified in the release template with the leaf node portion of their project file name.
If a release template is not specified or the Release Subdirectory field is left empty, then the items' project file names are used, relative to the operating system release folder the user requests for the release.