Share this page
Rule operation
This topic describes the guidelines for defining and using baseline rules for items in the Administration Console.
Guidelines
The following guidelines apply when defining baseline rules for item types:
-
Only one rule may be defined for each item type. For relevant items of that type, the rule is used to determine what status (lifecycle state) or build stage is acceptable, or to be preferred, for any revision to be included in a baseline.
-
To specify the rule, any one of the states or build stages in the normal lifecycle associated with that type may be chosen, together with one of the rules described in this topic, which determines how that state and others in the normal lifecycle are to be grouped and arranged in an order of preference.
A normal lifecycle consists of a single chain of states, starting with the first state at the beginning of the chain, and progressing upward through later states to the final state at the end of the chain.
-
For each relevant item of the type concerned within this rule, look at each grouping of normal lifecycle states in the order of preference indicated by the rule, until you find the first group which is not empty, where there is at least one revision of the relevant item in that group.
If you then find that there are two or more revisions in that group, you always select the revision which has been created/updated most recently. This is often the one with the highest entry in the revision field. If all groups in the order of preference are empty, that item is not included in any baseline specified using this template.
-
Except when an *ALL rule is used, no more than one revision of any item is selected for inclusion in a release baseline.
Rules for item types
The following table describes the rules that you can define for item types in the Administration Console.
| Rule | Grouping and order of preference |
|---|---|
| Latest from state (LFS) |
Latest from specified state and upward: there is just one group, and it consists of all revisions that are at any of the normal lifecycle states between the specified state and the final state, both of these states inclusive. Conversely, if a relevant item of the given type has all its revisions at states which are not in the normal lifecycle, and/or at states which are in the normal lifecycle but are below (earlier than) the specified state, then such a relevant item is not selected using this template. |
| Most progressed state above specified state or specified state (MPS) |
Most progressed state not below specified state: there are several groups, each of which includes revisions (if any) at just one lifecycle state. The order of preference for the groups is then:
Then so on downwards, ending with the group for the specified lifecycle state. |
| Specified state or most progressed state (SMP) |
Specified state or most progressed state: there are several groups, each of which includes revisions (if any) at just one lifecycle state. The order of preference for the groups is then:
Then so on downwards to earlier states, ending with the group for the next state upwards from the specified state. |
| Specified state or next existing state upward (SUP) |
Specified state or upward: there are several groups, each of which includes revisions, if any, at just one lifecycle state. The order of preference for the groups is then:
Then so on, ending with the group for the final state. |
| Specified state only (EQS) |
Equal to specified state: there is just one group – it consists of revisions which are at the specified lifecycle state only. (A relevant item of the given type, which has no revision at this state, is not selected using this template.) |
| Specified build stage and all next existing build stages upward (BUP) |
Latest from specified build stage and upward: there are several groups, each of which includes revisions (if any) at just one build stage. Conversely, if a relevant item of the given type has all its revisions at stages which are below the specified build stage, then such a relevant item is not selected using this template. The order of preference is then:
Then so on, ending with the group for the final stage. |
| Specified build stage only (EQB) | Equal to specified build stage: there is just one group, and it consists of revisions which are at the specified build stage only. (A relevant item of the given type, which has no revision at this stage, is not selected using this template.) |
Instead of specifying a particular state in the normal lifecycle, you can choose an implicit state. For details, see Rules using implicit states.
Example of rule operation
To illustrate the meaning of the different rules, consider the following abstract example where a normal lifecycle is defined as follows:
STATE 1 > STATE 2 > STATE 3 > STATE 4 > STATE 5
Suppose a rule is specified as STATE 2, along with the rule displayed in the left-hand column of the following table.
For a relevant item of the type concerned within this rule, the revision to be included in the baseline is the most recently updated revision chosen from those whose status is displayed in the following table:
| Rule | Selects latest revision from those: |
|---|---|
|
Latest from state (LFS) |
At any of the states: STATE 2, STATE 3, STATE 4, STATE 5. |
|
Most progressed state above specified state or specified state (MPS) |
At STATE 5; or else at STATE 4; or else at STATE 3; or else at STATE 2. |
|
Specified state or most progressed state (SMP) |
At STATE 2; or else at STATE 5; or else at STATE 4; or else at STATE 3. |
|
Specified state or next existing state upward (SUP) |
At STATE 2; or else at STATE 3; or else at STATE 4; or else at STATE 5. |
|
Specified state only (EQS) |
At STATE 2 only. |
In the first and last cases the item is not included in the baseline, if no revision meets the given requirement. In the middle three cases, we look at each "or else" in the list, only if no revision has been found which meets the requirements up to that point; the item is not included in the baseline, only if we reach the end of the list, still without success.
Suspended and checked out items
The following conditions apply for suspended and checked out items:
| Suspended item revisions |
If the selection is by a *ALL (which is for archiving only), any suspended status is ignored, and all revisions, both non-suspended and suspended, are selected for inclusion. Apart from *ALL, a suspended revision; is never selected for inclusion in a new release baseline, created using a baseline-template. The selection processes already detailed (apart from those for *ALL) are applied exactly as if the suspended revisions did not exist. Note: Suspended revisions can be found in existing template release baselines, due to having been selected for inclusion because they had not yet been suspended at the times when those baselines were created. Suspended revisions can also be included in new non-template baselines, such as revised and merged baselines. |
| Checked out item revisions |
A checked out revision is never included in a release baseline. Once a revision has been included in a release baseline, its file is no longer available to be checked out or altered in any way. If the selection is by an *ALL rule, and a checked out revision would have been among those selected (if it had not been checked out), then this is flagged, and the requested baseline is not created. Apart from *ALL rules, the selection processes already detailed are applied exactly as if the checked out revisions did not exist. |
| Suspended design parts |
The already given specifications apply to all relevant items which are either OWNED or USED by at least one non-suspended design part included in the baseline. But if any item is relevant only because all the included design parts, which either OWN or USE it, are SUSPENDED, then its processing is the same as for suspended Item revisions. All the revisions of such an item are processed as if they were suspended, regardless of their actual status. |
See also:
