Migrate Python SDK release process to Git-Tag-Driven Dynamic Versioning

[nan-yu]

Background

Currently, the a2ui Python SDK uses a manual version file approach where release versions are controlled by committing changes to agent_sdks/python/a2ui_agent/src/a2ui/version.py and/or agent_sdks/python/a2ui_core/src/a2ui/core/version.py before creating a Git tag.

While straightforward, this approach introduces several pain points:

• Merge Conflicts: Concurrent feature branches may experience conflicts when trying to update the version file or a static changelog.
• Dirty Git History: Every release requires metadata-only "version bump" commits.
• Complex Local Dev Testing: Generating accurate pre-release or development build numbers for testing in downstream applications is manual and error-prone.

We want to migrate to Git-Tag-First Dynamic Versioning. In this model, Git tags are the single source of truth. Build tools will dynamically infer and inject the version at build time using the repository's Git history (VCS).

Release Workflow

Phase	Version-file based	Git-Tag based
Source of Truth	Hardcoded version in version.py	Git Tag (e.g. v1.2.0)
PR Process	Must resolve version file conflicts on busy branches	No version file exists, zero PR merge conflict
CI Build Trigger	Direct push or merge of a version bump commit	Pushing a release tag
Changelog	Manually written or modified file	Auto-generated from Conventional Commits onto the GitHub Release Page

Implementation

• Update pyproject.toml to declare the version as dynamic and configure a VCS-based build backend (e.g. hatchling with hatch-vcs, or setuptools with setuptools-scm.
• Remove the hardcoded version files.
• Update the GitHub Action Release Workflow: Trigger the release workflow on tag creation (refs/tags/v*).
  Notes: This step is currently being blocked because the release has to be executed manually because of OSS Exit Gate integration. The OSS Exit Gate team is working on supporting GitHub action integration. Once this is done, we can automate the release process to be triggered on tag creation.
• Integrate Automated Changelog Generation
  • Configure GitHub Actions to automatically generate the changelog from commit history when publishing the GibHub Release.
  • Optionally, introduce git-cliff or configure conventional-changelog rules.