Skip to main content
Version: 19

Backward Compatibility Policy

As mentioned in our release policy, allowing daily deployments of custom code is crucial to achieve short delivery and testing cycles.

Speed should not come at the cost of stability. Therefore, we have a strict backward compatibility policy in place to:

  • Ensure that modifications to custom code do not break existing functionality
  • Avoid cross-organization impact

Backward compatibility is guaranteed by following these rules:

  • Existing custom code used in production cannot be modified in patch versions. Changes to custom code might be necessary in major versions due to changes to the platform or the interfaces.
  • Custom code is never automatically executed. The implementation classes must be explicitly configured.

Backward compatibility is achieved by versioning custom code classes. When modifications are requested, the class is copied and an incremented version is added to the class name. For example, if the class MyCustomCode requires changes, it will be copied and the modified version will be available as MyCustomCodeV2.

Only by adapting the configuration to use the new class, the new functionality is activated. This allows deploying patch versions to production even though the new class is not yet validated by the customer. This avoids the need to synchronize production deployments with the validation of custom code changes. Deploy daily, configure when ready.

API Gateway​

The API Gateway has a separate versioning strategy from the platform. We ensure backward compatibility within each major release of the API Gateway.