Appendix A Component Change Compatibility
This appendix enumerates the kinds of changes that can be made to a
component and indicates whether each change is install compatible or call
compatible.
The following changes can be made to components:
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
|
|
Reorder blocks
|
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
|
|
Change InstallBlock returns attribute value
|
No
|
Yes
|
|
Change UninstallBlock returns attribute value
|
No
|
No
|
|
Change ControlBlock returns attribute value
|
No
|
No
|
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.
以 PDF 格式下載這本書 (918 KB)