Description
Is your feature request related to a problem? Please describe.
We are preparing the repository for the first stable v1.0.0
release. Currently, the repo mixes global and backend-specific versioning inconsistently, the release automation for publishing the Python SDK is incomplete, and the README includes information that is not relevant to SDK users. This can create confusion for users and developers, and complicate maintenance over time.
Describe the solution you'd like
- Add global and backend-specific version tracking to
pyproject.toml
.- Global SDK version will be tracked via
[project] version
. - Internal backend versions (Java, Rust, C, etc.) will be tracked under
[tool.backend-versions]
.
- Global SDK version will be tracked via
- Make release automation consistent with Python ecosystem standards.
- Ensure
pyproject.toml
defines complete project metadata. - Ensure GitHub Actions (or equivalent) builds wheels and source distributions, checks them, and uploads to PyPI/TestPyPI.
- Releases will be tagged with the global version (e.g.,
v1.0.0
).
- Ensure
- Update the README.
- Focus exclusively on Python SDK usage.
- Remove low-level backend details from the main README (move to developer docs if necessary).
- Add a Quickstart, Installation, and Versioning Policy section specifically for SDK users.
Describe alternatives you've considered
- Keeping backend versions in a separate
backend_versions.json
file (rejected for now in favor of a unifiedpyproject.toml
approach). - Delaying full release automation until after
v1.0.0
(rejected because it is better to have clean CI/CD from the first stable release).
Additional context
- Backend versions will still be incremented independently (e.g., Java backend could move to
1.2.0
even if SDK stays at1.1.0
), but all versioning will be tracked cleanly. - Having a clean separation between SDK-facing information and backend-internal information will help users and future contributors.
- Related proposed tooling:
- Python
tomllib
/tomli
usage to load backend versions programmatically. - GitHub Actions workflow for publishing builds to PyPI.
- Python