Versioning and breaking changes

Scheme#

The SDK follows Semantic Versioning 2.0.0. The changelog follows Keep a Changelog.

Policy for 4.0#

The work after 3.0.0 ships as a new major version, 4.0.0. For that release the owner decided to remove deprecated features and to add no compatibility shims. A method that called an operation the API does not define is deleted without a deprecation period. The upgrade notes list each removal with its replacement.

The reason is that several 3.0.0 methods could not succeed against the live service, because of a wrong host, a request field the service rejects, or an operation with no path. Keeping those methods would let callers compile code that fails at run time.

What counts as breaking#

The following changes are breaking and are made in a major version only.

• removing or renaming a public class, method or enum constant
• changing a method signature or a return type
• changing default behaviour that callers rely on, for example what is retried, or what a builder sends by default

The following changes are not breaking and can be made in a minor or patch release.

• new methods, new overloads, new optional builder steps
• new enum constants. Read-side enums have an UNKNOWN fallback, and callers should handle it.
• reading additional response fields, or an additional response shape
• a fix that makes a request match the specification or the live service, when the previous request was rejected by the service

The last item is a judgment by the maintainer. It rests on the fact that a request the service always rejected has no caller whose code worked before the fix.

Beta surfaces#

A type annotated @Beta, and anything this site labels Beta, is exempt from the rules above. It tracks an Equinix API family or a third-party specification that can change without a deprecation period, and it may change in a minor SDK release. The annotation records the specification version the type follows.

The following are Beta in 4.0.

• everything under fabric.beta()
• provider environments, activation-key validation and the activationKey and environment access-point properties
• core.model.multicloud, including the ActivationKey codec
• native cloud-to-cloud planning and pricing in the design layer, and the two MCP tools for it

Bundled reference data is not covered by the versioning rules either. The reference prices and the multicloud environment catalog are dated copies of public pages, and any release can change their values.

Specification tracking#

Where the live service and a specification disagree, the SDK follows the live service on the read side, sends what the live service accepts on the write side, and documents the difference.

Release history#

The full text is in CHANGELOG.md.

Support#

One major version is maintained at a time, so 3.x receives no further fixes once 4.0.0 is published. The project offers no paid support and no service-level commitment (About).