Repository navigation
release: 0.49.0 - #64
Conversation
|
|
||
| ### Features | ||
|
|
||
| * **api:** sync generated SDKs from the committed spec ([5f13955](https://github.com/sentdm/sent-dm-python/commit/5f139558b459a76d7fd532ab4547461c9b1a280f)) |
There was a problem hiding this comment.
🔴 Customers get a 0.49.0 minor release with a Features line, "sync generated SDKs from the committed spec", that changes nothing they can see. The only commit in range, 5f13955, uses a feat(api): type but only bumps the editable sentdm version in uv.lock from 0.47.0 to 0.48.0. That type cuts a release, and its subject describes an internal pipeline step, not a customer-visible change. Fix: don't publish this release. Have the SDK pipeline use a hidden type such as ci: or test: for lockfile-only syncs, and save feat(api): subjects for real API changes. Close this release PR, or override its notes, until a customer-visible change lands.
Why this was flagged
The range 5f13955..HEAD holds one commit, feat(api): sync generated SDKs from the committed spec (Stainless-Generated-From 912e2ca). It touches only uv.lock, where the sentdm editable package version moves from "0.47.0" to "0.48.0". There is no API, model or client change. release-please treats feat: as releasable, so this PR bumps pyproject.toml, src/sent_dm/_version.py and .release-please-manifest.json to 0.49.0. It also adds CHANGELOG.md:8, which tells customers there is a new feature but names an internal process (a spec sync) and nothing they can use. Merging the release PR publishes 0.49.0 to PyPI, so customers get an empty minor release. REVIEW.md lists as Important "a type that cuts a release for a change customers don't see" and "an internal cause". CLAUDE.md says the subject must be written for customers, "Never an internal cause". The same pattern already shipped twice in 0.48.0, so it is recurring, not a one-off.
Verification: The trigger is merging this release PR, which publishes 0.49.0. The diff adds this line at CHANGELOG.md:8 under "### Features": "* api: sync generated SDKs from the committed spec (5f13955)". 5f13955, the only commit since v0.48.0, changes only uv.lock: the editable sentdm version goes from 0.47.0 to 0.48.0. It changes no API, model or client code, so customers get nothing new.
There was a problem hiding this comment.
The latest push brings this issue back at CHANGELOG.md:9:
🔴 Customers get a new 0.49.0 Features line about CI topology, an internal build detail they can neither see nor use. It comes from commit ca4dccc, typed feat(ci):. That commit only edits an echo line in scripts/utils/upload-artifact.sh. A feat type puts it in the changelog, while ci: would hide it. Fix: give CI-only generated commits a hidden type (ci:) in the SDK configuration, then regenerate this release so CHANGELOG.md drops the line. This differs from the posted 5f13955/uv.lock finding: that fix leaves this line in place.
Why this was flagged
The trigger is merging this release PR, which publishes 0.49.0 with the CHANGELOG.md:9 entry "* ci: run every SDK on the one-repo topology (ca4dccc)" under "### Features". Commit ca4dccc changes one line in scripts/utils/upload-artifact.sh: the pip install URL that the CI upload step echoes moves from sent-dm-python-staging to sent-dm-python. It does not touch the API, models or client. CLAUDE.md says "ci: and test: are hidden from the changelog" and that a subject must be written for customers, "Never an internal cause". REVIEW.md lists "a type that cuts a release for a change customers don't see" as Important. On the base branch the changelog has no such line. The existing [PRIOR] finding covers only the 5f13955 line at CHANGELOG.md:8 and its uv.lock cause. Fixing that leaves this line in place, because the feat type on ca4dccc still makes it releasable and visible.
Verification: Trigger: merging this release PR, which publishes 0.49.0 with its changelog. The diff adds CHANGELOG.md:9 under "### Features": "* ci: run every SDK on the one-repo topology (ca4dccc)". git show ca4dccc touches only scripts/utils/upload-artifact.sh (1 insertion, 1 deletion). Only "type": "ci" is "hidden": true, so the feat(ci): type is what surfaces the line.
| [project] | ||
| name = "sentdm" | ||
| version = "0.48.0" | ||
| version = "0.49.0" |
There was a problem hiding this comment.
🟣 pre-existing, not blocking: After merge, uv.lock still says 0.48.0, so the next generator run will cut a 0.50.0 release that changes nothing for customers. This release bumps pyproject.toml, .release-please-manifest.json and _version.py, but not the sentdm entry at uv.lock:1319. The generator then makes a feat(api) commit that touches only uv.lock, and that commit triggers the next release. Fix: the release PR must update the sentdm version in uv.lock together with pyproject.toml. One way is a release-please extra-files toml entry for uv.lock, changed through the SDK configuration because the config file is generator-owned.
A small fix can ride a push you are already making; otherwise a short reply is enough.
Why this was flagged
This diff changes pyproject.toml:3 to version = "0.49.0", but uv.lock:1319 still has version = "0.48.0" for the sentdm package. release-please-config.json lists only src/sent_dm/_version.py under extra-files, so release-please never updates uv.lock. The history shows the result. 5f13955 changes only uv.lock (0.47.0 -> 0.48.0) after release 0.48.0. 743d0d8 changes only uv.lock (0.46.0 -> 0.47.0) after release 0.47.0. Both are feat(api): sync generated SDKs from the committed spec commits, and each one cut the next minor release. Merging this PR leaves the same stale lock, so the cycle runs again and publishes another empty Features release. That is a different fix from the filed changelog-wording findings: those change the commit's type or text, while this fix keeps uv.lock in step with pyproject.toml so no sync commit is needed.
Verification: Trigger: the next generator (stlc-bot) sync runs after this merges. The diff does not touch uv.lock, which still reads version = "0.48.0" at uv.lock:1318-1319. In release-please-config.json, "extra-files": ["src/sent_dm/_version.py"] is the only extra file, so release-please never rewrites uv.lock. The base branch already goes through the same cycle.
fb30dbd to
3359161
Compare
There was a problem hiding this comment.
The latest push brings back an issue flagged in an earlier review; replied in that comment's thread.
Still open from earlier reviews (2):
- 🔴
CHANGELOG.md:8—Customers get a 0.49.0 minor release with a Features line, "sync generated SDKs from the committed spec", that changes… - Also unresolved: 1 minor or pre-existing.
If you have decided not to act on one of these findings, resolve its thread (a reply alone leaves it open) and the next review stops counting it. To review this commit again now, use Re-run on its "Claude Code Review" check.
|
🤖 Created releases: 🌻 |
Automated Release PR
0.49.0 (2026-10-30)
Maintenance
CLAUDE.md,REVIEW.md,CODEOWNERS). No API changes.This PR was generated with Release Please. See documentation.