Versioning Strategy

We try to avoid versioning our APIs as much as possible due to the increased maintenance cost and complexity managing multiple versions of the same APIs.

We do this by enforcing forward and backward compatibility on API changes to the widest possible extent.

When there is no way to avoid it, we do support two versions for at limited time. The current and the version before that.

In the event of a breaking change / new version the following process will occur

The product subscription owner will be notified of the deprecation along with a description of what steps should be taken 1 month ahead of time

1. The new version will be added as latest version, but will not receive traffic pr default

2. The product subscription owner will be notified of the deprecation 1 week ahead of time

3. The new version will be marked as default, and traffic is routed to it by default

4. The old version will be marked as deprecated and will no longer receive traffic, but still be reachable via the steps in 1)

5. The old version is terminated