Historic Breaking Changes

This document outlines the breaking changes introduced in API7 Enterprise across different versions. These changes may affect your existing configurations and workflows. Please review the changes for your target version before upgrading to ensure a smooth transition.

3.8.19

Release Date: 2025-12-09

• AI Rate Limiting: The ai-rate-limiting plugin now requires a new policy field. Existing configurations continue to function on the data plane, but any updates must include policy: local; otherwise, the update will be rejected.

3.8.18

Release Date: 2025-11-25

• To support creating multiple Portal instances, the portal-auth plugin of the data plane has been upgraded. After upgrading the control plane, users should upgrade the data plane as soon as possible. During the period between the control plane upgrade and the data plane upgrade completion, please do not update existing API products, as such changes will not take effect.

3.8.10

Release Date: 2025-08-25

• Removed the ext-plugin-pre-req, ext-plugin-post-req, and ext-plugin-post-resp plugins from the Enterprise Edition.

3.8.1

Release Date: 2025-05-07

• Request ID: Removed the snowflake algorithm from the request-id plugin due to potential risks.

3.6.0

Release Date: 2025-02-26

• Removed service runtime configurations in service templates, for better template reuse across gateway groups. Existing service runtime configurations within service templates will be removed, but your published service configurations will remain unchanged. Furthermore, the publishing process is simplified and streamlined, with no service runtime configurations allowed during the process. See the updated guide to publish service.

warning

ADC Version Compatibility: Starting from this version, API7 Enterprise is no longer compatible with ADC versions before 0.18.0. Please ensure you are using ADC 0.18.0 or higher to avoid compatibility issues.

3.5.0

Release Date: 2025-01-27

• Multiple Upstreams in a Service: For advanced scenarios such as canary deployments, blue-green deployments, or managing multiple clusters, a service can now utilize multiple upstreams. In such cases, a default upstream serves as the primary target for most requests, while other upstreams can be used for specific purposes, such as routing traffic to a canary deployment or a secondary cluster. See the renewed Configure Canary Traffic Shifting for details.

warning

The old Canary Rule function is no longer available.