Changes That Can Be Made To Components
<component> Element Changes
The following table shows the changes that can be made to the <component> element and indicates whether each change is install compatible or call compatible.
Type of Change
|
Install Compatible
|
Call Compatible
|
Nonfinal to final
|
No
|
Yes
|
Final to nonfinal
|
Yes
|
Yes
|
Nonabstract to abstract
|
No
|
Yes
|
Abstract to nonabstract
|
Yes
|
Yes
|
More restrictive access
|
No
|
No
|
Less restrictive access
|
Yes
|
Yes
|
Change the value of the description, label, softwareVendor, or author attributes
|
No [The attribute values are stored in the installed variable settings record.]
|
Yes
|
Change the value of the name or path attributes [This change effectively constitutes a change of the version tree and is only possible in situations where a system service is being updated. In this case, the new component must be an instance of the original component.]
|
No
|
Yes
|
Change from a simple component to a composite component
|
No
|
No
|
Change from a composite component to a simple component
|
No
|
No
|
platform Attribute Changes
The following table shows the changes that can be made to the platform attribute and indicates whether each change is install compatible or call compatible.
Type of Change
|
Install Compatible
|
Call Compatible
|
More general platform
|
Yes
|
Yes
|
More specific platform
|
No
|
Yes
|
Unrelated platform
|
No
|
Yes
|
A platform is more specific than another if the first platform is a descendant of the second. A platform is more general if the first platform is an ancestor of the second platform.
limitToHostSet Attribute Changes
The following table shows the changes that can be made to the limitToHostSet attribute and indicates whether each change is install compatible or call compatible.
Type of Change
|
Install Compatible
|
Call Compatible
|
Any change to the limitToHostSet attribute
|
No
|
Yes
|
Unlike the platform attribute, limitToHostSet names a generic, user-specified host set over which there is no explicit control. A host set's membership can change at any time, so you cannot specify more-specific or less-specific host sets.
<extends> Element Changes
The following table shows the changes that can be made to the <extends> element and indicates whether each change is install compatible or call compatible.
Type of Change
|
Install Compatible
|
Call Compatible
|
New base component instance of the original component
|
No
|
Yes
|
Original base component instance of a new component
|
No
|
No
|
New base component that is unrelated to the original component
|
No
|
No
|
New base component is install compatible with the original component
|
Yes
|
Yes
|
New base component is call compatible with the original component
|
No
|
Yes
|
Changes to Variables
The following table shows the changes that can be made to a variable and indicates whether each change is install compatible or call compatible.
Type of Change
|
Install Compatible
|
Call Compatible
|
Add a new variable
|
Yes [A derived component might exist that already defines the variable with a more restrictive access mode. In such a case, a change would make the derived component invalid. A new nonabstract variable can be added to a component type if no derived component has already defined a variable that has the same name, and the default value of the variable can be recomputed for all installed instances of the component.]
|
Yes
|
Remove or rename a nonprivate variable
|
No
|
No
|
Remove or rename a private variable
|
Yes
|
Yes
|
Change the default value of a final variable
|
No
|
Yes
|
Change the default value of a nonfinal variable
|
Yes [No reinstall is required because the installed value can be considered an override of the new default value.]
|
Yes
|
Change the prompt attribute
|
Yes
|
Yes
|
Nonfinal to final
|
No
|
Yes
|
Final to nonfinal
|
Yes
|
Yes
|
Nonabstract to abstract
|
No
|
Yes
|
Abstract to nonabstract
|
Yes
|
Yes
|
More restrictive access
|
No
|
No
|
Less restrictive access
|
Yes
|
Yes
|
<targetRef> Element Changes
The following table shows the changes that can be made to the <targetRef> element and indicates whether each change is install compatible or call compatible.
Type of Change
|
Install Compatible
|
Call Compatible
|
Remove <targetRef> element
|
No
|
No
|
Add <targetRef> element
|
No
|
Yes
|
Modify the hostName attribute
|
Yes [The attributes of hosts that are associated with existing installed components are not updated as a result of such a change.]
|
Yes
|
Modify the typeName attribute
|
No
|
No
|
Add or remove an <agent> child element
|
No
|
No
|
Modify the connection attribute of the <agent> child element
|
Yes
|
Yes
|
Modify the ipAddr attribute of the <agent> child element
|
Yes
|
Yes
|
Modify the port attribute of the <agent> child element
|
Yes
|
Yes
|
Modify the params attribute of the <agent> child element
|
Yes
|
Yes
|
<componentRefList> Element Changes
The following table shows the changes that can be made to the <componentRefList> element and indicates whether each change is install compatible or call compatible.
Type of Change
|
Install Compatible
|
Call Compatible
|
Nonfinal to final
|
No
|
Yes
|
Final to nonfinal
|
Yes
|
Yes
|
New type instance of the original
|
No
|
Yes
|
Original type instance of the new
|
No
|
No
|
New type that is unrelated to the original
|
No
|
No
|
New type is install compatible with the original
|
Yes
|
Yes
|
New type is call compatible with the original
|
No
|
Yes
|
<componentRef> Element Changes
The following table shows the changes that can be made to the <componentRef> element and indicates whether each change is install compatible or call compatible.
Type of Change
|
Install Compatible
|
Call Compatible
|
Nonfinal to final
|
Yes [A derived component might exist that already defines the component reference with a more restrictive access mode or otherwise incompatible difference. In such a case, a change would make the derived component invalid. A new nonabstract component reference can be added to a component type if no derived component has already defined a component reference that has the same name.]
|
Yes
|
Final to nonfinal
|
Yes
|
Yes
|
Nonabstract to abstract
|
No
|
Yes
|
Abstract to nonabstract
|
Yes
|
Yes
|
Change the installMode attribute
|
No
|
No
|
Add a new component reference
|
Yes, [Adding a nested component is technically possible. An existing installation would be treated as if it had been installed without the nested component. Because any functionality that might depend on the installation could break, this change should only be made if the component can function safely without the nested component. Otherwise, it should be treated as being a change that is not install compatible.]
|
Yes
|
Remove or rename a nested <componentRef>
|
No
|
No
|
Remove or rename a top-level <componentRef>
|
No
|
No
|
Add, modify, or remove arguments from a nested component's <argList>
|
No
|
Yes
|
Add, modify, or remove arguments from a top-level component's <argList>
|
Yes [You cannot determine whether this component was the component that actually installed the top-level component. Therefore, this component cannot rely on the top-level component having variables that correspond to the <argList> values.]
|
Yes
|
New type instance of the original
|
No
|
Yes
|
Original type instance of the new
|
No
|
No
|
New type that is unrelated to the original
|
No
|
No
|
New type that is install compatible with the original
|
Yes
|
Yes
|
New type that is call compatible with the original
|
No
|
Yes
|
New nested component instance of the original
|
No
|
Yes
|
Original nested component instance of the new
|
No
|
No
|
New nested component that is unrelated to the original
|
No
|
No
|
New nested component that is install compatible with the original
|
Yes
|
Yes
|
New nested component that is call compatible with the original
|
No
|
Yes
|
Changes to Resources
The following table shows the changes that can be made to a resource and indicates whether each change is install compatible or call compatible.
Type of Change
|
Install Compatible
|
Call Compatible
|
Nonfinal to final
|
No
|
Yes
|
Final to nonfinal
|
Yes
|
Yes
|
Nonabstract to abstract
|
No
|
Yes
|
Abstract to nonabstract
|
Yes
|
Yes
|
Modify the installPath, name, group, or user attributes
|
No
|
Yes
|
Modify the rsrcName or rsrcVersion attributes
|
No
|
Yes
|
<install>, <control>, and <uninstall> Block Changes
The following table shows the changes that can be made to an <install>, <control>, or <uninstall> block and indicates whether each change is install compatible or call compatible.
Type of Change
|
Install Compatible
|
Call Compatible
|
Nonfinal to final
|
Yes [A derived component might exist that already defines the block with a more restrictive access mode or otherwise incompatible difference. In such a case, a change would make the derived component invalid. A new nonabstract block can be added to a component type if no derived component has already defined a block that has the same name.]
|
Yes
|
Final to nonfinal
|
Yes
|
Yes
|
Nonabstract to abstract
|
No
|
Yes
|
Abstract to nonabstract
|
Yes
|
Yes
|
More restrictive access
|
No
|
No
|
Less restrictive access
|
Yes
|
Yes
|
Add a new nonprivate block
|
Yes
|
Yes
|
Add a new private block
|
Yes
|
Yes
|
Remove or rename a nonprivate block
|
No
|
No
|
Remove or rename a private block
|
Yes
|
Yes
|
Change the body of a block
|
Yes [The plan run history of prior runs of this block are not updated. Therefore, they might not directly coincide with the new block contents.]
|
Yes
|
Add, modify, or remove local block variables
|
Yes
|
Yes
|
Add, modify, or remove private block parameters
|
Yes
|
Yes
|
Add a required parameter to a nonprivate block
|
No
|
No
|
Add an optional parameter
|
Yes
|
Yes
|
Remove an optional or a required parameter
|
Yes [Extra arguments that are passed from the caller are ignored, making this change possible.]
|
Yes
|
Rename an optional parameter
|
Yes [This change is equivalent to removing and adding an optional parameter. However, the callers might see unexpected results as the originally passed parameter value is now ignored and replaced with the default value.]
|
Yes
|
Rename a required parameter from a nonprivate block
|
No
|
No
|
Change a parameter from being optional to being required in a nonprivate block
|
No
|
No
|
Change a parameter from being required to being optional
|
Yes
|
Yes
|
Change the displayMode attribute of a parameter
|
Yes
|
Yes
|
Change the prompt attribute of a parameter
|
Yes
|
Yes
|
Changes to <snapshot> Blocks
The following table shows the changes that can be made to the <prepare>, <cleanup>, or <capture> child elements of the <snapshot> element and indicates whether each change is call compatible or install compatible. <snapshot> blocks generally have the same compatibility matrix as the other blocks, except when dealing with their <prepare>, <capture>, and <cleanup> blocks.
Type of Change
|
Install Compatible
|
Call Compatible
|
Add, modify, or remove a <prepare> or <cleanup> block
|
Yes
|
Yes
|
Add, modify, or remove a <capture> step
|
Yes [The contents of the snapshot <capture> block are evaluated only one time. The evaluation takes place when the snapshot is taken during initial installation. At comparison time, the stored capture contents are used to drive the comparison, ignoring any changes that might have occurred to the <capture> block. Thus, the existing snapshot is not affected by such a change. If the intent of the change was to affect the contents of the existing snapshot, this change must be modeled as a change that is not install compatible.]
|
Yes
|
Changes to <ignore> Child of <diff> Element
The following table shows the changes that can be made to the <ignore> child element of the <diff> element and indicates whether each change is call compatible or install compatible.
Type of Change
|
Install Compatible
|
Call Compatible
|
Add, modify, or remove an <ignore> element
|
Yes
|
Yes
|
The <ignore> element is only considered when you run the comparison and does not affect the state of existing snapshots.