The Python CLI and SDK need a clearer release policy.
We have already seen repeated PyPI publish failures because regular main branch changes were able to trigger package publishing, while PyPI versions and filenames cannot be reused once published. The stopgap change in #271 prevents the immediate failure mode, but we still need to define how Python packages in this repository should be versioned and released.
I would like to propose the following policy.
Proposal
Stable releases of agentcube-cli and agentcube-sdk should follow the AgentCube release version and should be published only from release tags.
For example, when we cut an AgentCube release such as v0.2.0, the Python CLI and SDK should publish stable package versions derived from that same release, instead of being published independently from normal main branch changes.
Regular development on main should not publish to the public PyPI stable channel.
If we need installable builds for testing before a release, we should use a separate path:
- preferably TestPyPI, or
- uniquely versioned pre-releases such as
.devN if we decide we want them on PyPI
We should also avoid maintaining unrelated package versions by hand in multiple places. A follow-up change should introduce a single source of truth for the Python package version so that the CLI and SDK stay aligned with the intended release version.
Expected workflow
- Normal PRs merge into
main without publishing stable Python packages.
- Release preparation decides the next AgentCube version.
- A release tag triggers stable publishing for the Python CLI and SDK.
- Pre-release or test builds, if needed, go through TestPyPI or uniquely versioned development releases.
Why this direction
This keeps Python package publishing aligned with the overall project release flow, avoids repeated PyPI failures, and makes the release behavior much easier to understand.
Follow-up work
If there is agreement on this direction, the next PRs can cover:
- version source unification for the Python packages
- a test-build path for development releases
- final cleanup of the current publish workflows
Related:
The Python CLI and SDK need a clearer release policy.
We have already seen repeated PyPI publish failures because regular
mainbranch changes were able to trigger package publishing, while PyPI versions and filenames cannot be reused once published. The stopgap change in #271 prevents the immediate failure mode, but we still need to define how Python packages in this repository should be versioned and released.I would like to propose the following policy.
Proposal
Stable releases of
agentcube-cliandagentcube-sdkshould follow the AgentCube release version and should be published only from release tags.For example, when we cut an AgentCube release such as
v0.2.0, the Python CLI and SDK should publish stable package versions derived from that same release, instead of being published independently from normalmainbranch changes.Regular development on
mainshould not publish to the public PyPI stable channel.If we need installable builds for testing before a release, we should use a separate path:
.devNif we decide we want them on PyPIWe should also avoid maintaining unrelated package versions by hand in multiple places. A follow-up change should introduce a single source of truth for the Python package version so that the CLI and SDK stay aligned with the intended release version.
Expected workflow
mainwithout publishing stable Python packages.Why this direction
This keeps Python package publishing aligned with the overall project release flow, avoids repeated PyPI failures, and makes the release behavior much easier to understand.
Follow-up work
If there is agreement on this direction, the next PRs can cover:
Related: