Developer Guidelines
--------------------

The following practices are recommended to all developers.
The aim is to reduce the number and extent of any updates that may be necessary.

1. The order of elements within the interface data and messages may change, within the constraints of the interface specification. 
   Developers should avoid unnecessary dependence on the order of elements to interpret information exchanged with |VOSS Automate|.
#. New interface methods, operations, actions, requests, responses, headers, parameters, attributes, 
   other elements, or new values of existing elements, may be introduced into the |VOSS Automate| interfaces. 
   Developers should disregard or provide generic treatments where necessary for any unknown elements or unknown values of known 
   elements encountered.
#. Notifications, operations, methods, actions, requests, responses, headers, parameters, attributes, and other elements 
   from previous versions of |VOSS Automate| interfaces, will remain, and will maintain their previous meaning and behavior 
   to the extent possible and consistent with the need to correct defects.
#. Applications should not be dependent on interface behavior resulting from defects (behavior not consistent with published 
   interface specifications), since the behavior can change when defects are fixed.
#. The use of deprecated methods, operations, actions, handlers, requests, responses, headers, parameters, attributes, 
   or other elements should be removed from applications as soon as possible to avoid issues when those deprecated items are 
   removed from |VOSS Automate| or its interfaces.
#. Application Developers should be aware that not all new features and new supported devices (for example, phones) will be forward 
   compatible. New features and devices may require application modifications to be compatible or to make use of the new features or devices.

.. |VOSS Automate| replace:: VOSS Automate
.. |Unified CM| replace:: Unified CM