chore: migrate from python-semantic-release to release-please

Summary

Replace python-semantic-release (pip) with release-please (GitHub Action) for automated versioning and publishing. This eliminates the ci dependency group entirely (~10 transitive packages) and requires zero local release tooling.

Background

We are switching to standard semver (major locked to server minor). The custom server:/server-major: commit types are no longer needed. release-please supports standard conventional commits natively with zero local dependencies.

Changes required

1. Add release-please config

Create release-please-config.json:

{
  "release-type": "python",
  "prerelease": true,
  "prerelease-type": "dev",
  "include-component-in-tag": false,
  "packages": {
    ".": {
      "package-name": "camunda-orchestration-sdk"
    }
  }
}

Create .release-please-manifest.json with the current version.

2. Rewrite publish workflow

Replace the current publish.yml with a single workflow that:

1. Job 1: Generate + test + commit drift (existing logic from the test matrix + generate jobs)
2. Job 2 (needs Job 1): Run googleapis/release-please-action@v4
   • If releasable commits exist → opens/updates a release PR → gh pr merge --auto --squash
   • If merged release PR detected → release_created=true → uv build + PyPI publish via OIDC trusted publishing

Requires a PAT or GitHub App token (stored as RELEASE_PAT secret) so that PR merge triggers the next workflow run.

3. Handle stable/* branches

Use target-branch: ${{ github.ref_name }} to support both main (dev prereleases) and stable/* (stable releases). On stable/* branches, set "prerelease": false in the config.

4. Remove old release tooling

• Remove python-semantic-release from the ci dependency group in pyproject.toml
• Remove the entire ci dependency group if it becomes empty
• Remove [tool.semantic_release] config section from pyproject.toml
• Update CI workflows to remove --group ci from uv sync commands
• Note: release-please updates pyproject.toml version natively via the python release type — the version_toml config is no longer needed

5. Version file handling

release-please's python strategy knows how to update:

• pyproject.toml (project.version)
• setup.py / setup.cfg (if present)
• CHANGELOG.md

If additional files need version updates, use extra-files with the TOML updater.

6. Keep existing functionality

• CHANGELOG.md generation (built into release-please)
• GitHub Release creation
• PyPI publish via OIDC trusted publishing (pypa/gh-action-pypi-publish)
• Version validation against stable branch constraints

Considerations

• PAT requirement: GITHUB_TOKEN events don't trigger workflows. A fine-grained PAT or GitHub App token (scoped to this repo, contents: write + pull-requests: write) is needed for auto-merge to trigger the publish run.
• Latency: Similar to current flow. Push → PR updated (~30s) → CI → auto-merge → publish.
• Generated code drift: Must be committed before release-please runs. Keep drift commit in Job 1, release-please in Job 2.
• Prerelease token: Python uses dev (PEP 440 compliant), not alpha. Configure "prerelease-type": "dev" in release-please config.

Start by inspecting pyproject.toml and the existing publish.yml, along with the current test matrix and generate jobs. Add the named release-please configuration and workflow, remove the semantic-release dependency and settings, and verify generated-code drift, stable-branch version validation, release creation, and PyPI publishing remain covered.