chore: automate SemVer bumps with Release Please

[Vinay Shende (vinay79n)]

Summary

• Adds Release Please so pyproject.toml / uv.lock versions are bumped from Conventional Commit PR titles (SemVer: fix: patch, feat: minor, feat!: breaking).
• Feature PRs must not edit project.version. After merge, a separate release PR is opened; merging that PR tags vX.Y.Z and creates a GitHub Release.
• Replaces the old check-version / tag-version jobs. CI now rejects manual version bumps and requires a conventional PR title. README documents titles, squash-merge, and FAQ.

Current version is seeded at 0.6.1. While on 0.y.z, breaking changes bump minor (not 1.0.0).

After merge

• Enable Allow GitHub Actions to create and approve pull requests (Settings → Actions → General).
• Squash-merge future PRs so the title is the commit Release Please reads.
• This chore: PR will not cut a release. The next fix: / feat: / docs: on main will open the first release PR.

Release Please — demo evidence

Same setup as this PR: Python Release Please, versions from squash-merge PR titles, no version edits on feature PRs, bot release PR updates pyproject.toml / uv.lock / CHANGELOG.md and tags vX.Y.Z.

Proven in release-please-test-repo.

What we ran

1. Setup — Merged PR #1 (chore:). Turned on Allow GitHub Actions to create and approve pull requests. Release Please ran and opened no release PR. Version stayed 0.1.0. The version-guard failure on this first PR was expected (None → 0.1.0 because main had no pyproject.toml yet).

2. Single PATCH — Merged PR #2 (fix:). Bot opened PR #3 at 0.1.1. Merging it tagged v0.1.1.

3. Highest bump wins — Merged PR #4 (fix:). Bot PR went to 0.1.2. Then merged PR #5 (feat:) before cutting the release. Bot PR updated to 0.2.0 (not 0.1.2, not 0.1.3). Merging PR #6 tagged v0.2.0. Changelog listed both the fix and the feat.

What this proves

• chore: does not bump.
• fix: → PATCH; feat: → MINOR.
• Several unreleased PRs → one release PR at the max bump.
• Feature PRs do not touch version files; only the bot PR does.
• Merge the bot PR when you want the GitHub Release and v* tag.

Test plan

• Confirm CI is green (PR title lint, no version-guard failure).
• After merge, confirm the Release Please workflow runs on main and does not open a release PR (chore only).
• Enable Actions permission to create PRs if the bot cannot open a release PR later.
• On a later fix: or feat: merge, confirm a release PR bumps pyproject.toml and CHANGELOG.md.

[Copilot]

🟡 Changes recommended

Unresolved workflow, lockfile validation, release filtering, and fork-support issues block approval.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Automates SemVer releases with Release Please, Conventional Commit validation, version guards, and updated documentation.

Changes:

• Adds Release Please configuration, manifest, and workflow.
• Validates PR titles and replaces manual release checks.
• Documents release and versioning conventions.

File summaries

File	Summary
release-please-config.json	Configures Python releases; moderate issue: non-release commit types still trigger patch releases.
README.md	Documents release operations; nit: PAT guidance omits issues: write.
.release-please-manifest.json	Seeds version 0.6.1.
.github/workflows/release-please.yaml	Runs automated release management on main.
.github/workflows/lint-pr-title.yaml	Validates titles; moderate issue with fork PR support under pull_request.
.github/workflows/ci-cd-ds-platform-utils.yaml	Adds version guards; critical bypass risk via branch naming and moderate incomplete uv.lock validation.

Review details

Suppressed comments (3)

.github/workflows/lint-pr-title.yaml:4

• Using pull_request means this check cannot reliably validate fork-based PRs: the action's v6 documentation notes that this trigger has no usable token for fork PRs, so the required title check errors or is unavailable to external contributors. This workflow only reads PR metadata, so use pull_request_target without checking out PR code.

  pull_request:

README.md:123

• These instructions omit issues: write, but the Release Please action's workflow example grants contents, issues, and pull-requests write permissions. The workflow-level permissions do not apply to a replacement PAT, so a PAT configured with only the two permissions listed here can fail while labeling or managing the release PR.

Enable **Allow GitHub Actions to create and approve pull requests** under **Settings → Actions → General**. To run CI on the release PR, point `release-please.yaml` at a PAT with `contents` and `pull-requests` instead of `GITHUB_TOKEN`.

release-please-config.json:3

• With the Python strategy, every parsed conventional commit is passed to the default versioning strategy; anything that is not feat or breaking falls through to a patch bump. As a result, this merge's chore: commit (and the documented ci:, test:, refactor:, style:, or build: commits) will still open a release PR for 0.6.2, contradicting the README and PR summary. Add a reliable commit filter/wrapper or revise the documented policy so the configured behavior matches the stated release rules.

  "release-type": "python",

• Files reviewed: 6/6 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.