In general, deprecation is used to identify something as not available in future versions and therefore should be avoided. Something is deprecated when its capabilities are replaced by something else or when it does not support necessary requirements.
OPC UA defines a mechanism to identify Nodes in an Information Model as deprecated by using the IsDeprecated ReferenceType pointing from the deprecated Node to some information identifying the version when it has been first deprecated.
In general, the reason to use this feature in an Information Model is to mark some Nodes not to be used anymore, if possible. Often, there are other Nodes in the Information Model to be used instead of. The deprecated Nodes are still available so that Clients developed and configured against an older version of the Information Model are still working. New Clients or new configurations of the old Clients should not use the deprecated Nodes anymore as future versions of the Information Model will not have those Nodes anymore. This allows a smooth transition from the old, deprecated Nodes to the new Nodes without immediately breaking the Clients, and still avoids that a new Client or the configuration of an old Client uses the deprecated Nodes.
From a Client’s perspective, it should avoid using the deprecated Nodes. The only reason to use them is to be compatible with older versions of the Information Model. If this is required, the Client should ideally have two paths to access the Information Model. The default should be the access using the new Nodes. If the new Nodes are not available in older versions of the Information Model, the deprecated Nodes may be used as a backup access path.
Breaking changes are not allowed in a released NamespaceUri of a Companion Specification. If a Companion Specification needs a breaking change, it needs to create a new NamespaceUri and thereby create a new Information Model (see 3.3).
Marking a Node as deprecated is less helpful in a Companion Specification because that deprecated Node can never be removed from the existing NamespaceUri. However, a Companion Specification may still define a new mechanism for a specific functionality and deprecate the old mechanism without a breaking change. This gives Clients at least a hint that there is a better way to access the information. Nevertheless, Clients need to consider that old versions of the Companion Specification only had the deprecated mechanism, and they still need to be able to use it, if they want to support older versions of the Companion Specification. Servers may still support the deprecated and the new mechanism, in order to support old Clients. If the deprecated Node is Mandatory, the Servers have to support the old, deprecated mechanism, even if no Client uses the old, deprecated Node.
An alternative to marking Nodes as deprecated is to create a new NamespaceUri (see 3.3). This makes it clear what a Server supports and what a Client can access. A potential transition phase of a product supporting the Companion Specification is supporting both NamespaceUris.
For Companion Specifications, it is recommended to create a new NamespaceUri with the new mechanism instead of marking Nodes as deprecated and adding the new mechanism to the existing NamespaceUri. A new NamespaceUri introduces a model free of ambiguity. The exceptions to the recommendation are small changes like deprecating an optional InstanceDeclaration, and DataTypes, ObjectTypes and VariableTypes only used for this InstanceDeclaration.
In order to manage several changes over time, Companion Specifications may use the deprecation mechanism in one version if they can already foresee a breaking change in another upcoming version, in order to avoid too many new NamespaceUris.
When Nodes are marked as deprecated in a Companion Specification, it is recommended to create an Object as child of the NamespaceMetadata Object of the Companion Specification and point to that Object using the IsDeprecated ReferenceType. The BrowseName of the Object should indicate the deprecation and the version of the deprecation, e.g., “<SpecName>Version1_02”. An example is the version 1.02 of OPC 40501-1.
___________