The README states:
WorkOS follows Semantic Versioning. Breaking changes are only released in major versions. We strongly recommend reading changelogs before making major version upgrades.
It links to https://semver.org/, which defines SemVer as:
MAJOR version when you make incompatible API changes
MINOR version when you add functionality in a backward compatible manner
PATCH version when you make backward compatible bug fixes
That is not what the Python SDK is currently doing.
Since v8.0.0, every minor release after the major version has included an explicit ⚠️ Breaking section:
A concrete downstream breakage: v8.2.0 includes SDK surface change: Symbol "AsyncPipes.create_data_integration_token" was removed.
Removing public SDK surface area in a minor release is a breaking change, as correctly stated in the release notes, however it directly contradicts the README’s stated versioning policy.
Please either:
- follow the documented SemVer policy and only ship breaking SDK changes in major versions; or
- update the README to stop claiming SemVer compatibility and clearly tell users that minor SDK releases may contain breaking changes.
This has real downstream consequences because users choose dependency constraints based on the documented compatibility contract. If minor versions can break, production users need to know to pin exact SDK versions instead of trusting 8.x compatibility.
The README states:
It links to https://semver.org/, which defines SemVer as:
That is not what the Python SDK is currently doing.
Since
v8.0.0, every minor release after the major version has included an explicit⚠️ Breakingsection:[v8.1.0][v8.2.0]A concrete downstream breakage:
v8.2.0includesSDK surface change: Symbol "AsyncPipes.create_data_integration_token" was removed.Removing public SDK surface area in a minor release is a breaking change, as correctly stated in the release notes, however it directly contradicts the README’s stated versioning policy.
Please either:
This has real downstream consequences because users choose dependency constraints based on the documented compatibility contract. If minor versions can break, production users need to know to pin exact SDK versions instead of trusting
8.xcompatibility.