Define a release policy for Python packages

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

1. Normal PRs merge into main without publishing stable Python packages.
2. Release preparation decides the next AgentCube version.
3. A release tag triggers stable publishing for the Python CLI and SDK.
4. 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:

• #249
• #271

Review #271 and #249 along with the current Python package publishing workflows; the issue names no files or tests, so first map where agentcube-cli and agentcube-sdk versions and publish triggers are defined. Done means the release-tag workflow, version source, and TestPyPI or pre-release path are agreed and documented without main publishing stable packages.