Breaking Changes Policy
Â
Abstract
As the Transporeon platform evolves, we add new functionality and changes to our interfaces every month.
Changes that are considered non-breaking are released without prior notice. If a change is considered otherwise as breaking, Transporeon will make a reasonable effort to separate it to a new interface version and/or notify customers in advance to give sufficient time to adapt.
Note, we do our best to avoid any change that can be considered as breaking to keep efforts for customers low.
Breaking Change
A breaking change that may require you to adapt your system to continue using integration with Transporeon. See following examples:
renaming fields of objects or resource names and paths
removing fields of inbound or outbound messages or changing their data type
adding mandatory fields to an existing object without default values
changing logic of an existing endpoint without backwards-compatibility
Non-Breaking Change
Following is a list of changes examples that are considered as non-breaking:
introducing new objects and resources, used in new inbound and outbound messages
adding new methods for existing resources
adding logic to an existing resource, without changing behavior
adding to outbound exports mandatory fields with default values
adding new fields, measurements, and parameters in outbound messages
introducing optional headers, fields, and parameters in inbound messages
changing sizes of lists in outbound messages
introduce new error messages or changing their text in responses.
Â