8000 Prepare for v1.0.0 release · Issue #130 · codellm-devkit/python-sdk · GitHub
[go: up one dir, main page]

Skip to content
Prepare for v1.0.0 release #130
Closed
Closed
@rahlk

Description

@rahlk

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].
  • 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).
  • 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 unified pyproject.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 at 1.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.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

    0