release(deepagents): 0.7.1 - #5170
Mason Daugherty (mdrxy) merged 3 commits into
Conversation
bea3dc2 to
7c1bfaf
Compare
7c1bfaf to
e89bc78
Compare
|
Review and edit the release notes between the content markers below as needed. Keep the version heading intact. 0.7.1 (2026-07-30)Features
Bug Fixes
When the release changes are finalized, run: Merge only after the curated release-notes check passes. If new relevant entries appear after applying, draft again and then re-apply: To ship without curated notes, add the |
|
release-bot apply |
|
Curated release notes were applied to the package changelog and release PR body. Do not add more |
|
The package release workflow has started: Follow the linked run for build, test, and publish status. |
…5206) Release PRs opened or updated by release-please get their `uv.lock` files regenerated again. The `update-lockfiles` job was silently skipping on every push to `main` — the workflow showed green while release PR lockfiles went stale and the "🔒 Check Lockfiles" workflow failed on them — because #5161 put the legitimately-skipped `trigger-releases` job in its upstream `needs` chain and the job's bare `if:` kept GitHub Actions' implicit `success()` gate. #5169 fixed this for the `release-please` job; this applies the same gating to `update-lockfiles` (and audits the remaining downstream jobs). --- ## Why `update-lockfiles` needs `release-please`, which (after #5161) transitively needs `trigger-releases` via `guard-pending-release`. On ordinary pushes to `main`, `trigger-releases` is skipped — and without a status-check function in the job's `if:`, Actions' implicit `success()` gate on the whole `needs` chain fails closed. The job was skipped with an all-green workflow; observed on release PR #5170, where lockfiles had to be regenerated by hand. ## Fix - `update-lockfiles`: `!cancelled()` plus explicit `result == 'success'` checks on every dependency in the chain (`guard-empty-commit`, `detect-release-commit`, `guard-pending-release`, `release-please`), keeping the existing `prs != '[]' && prs != ''` requirement. Fail-closed semantics preserved: a crashed guard or unset `prs` still blocks the job. `trigger-releases` is deliberately not re-checked — on release commits, `release-please` succeeding already implies the guard saw the dispatch succeed. - `dispatch-release-notes-check`: audit found its `always()` gate already survived the skipped-`trigger-releases` case, but would also run after a cancelled workflow or red guardians. Added `!cancelled()` and the same hand-checked ancestor results; `update-lockfiles` stays a sequencing-only need whose own failure does not block the dispatch. - `guard-empty-commit`, `detect-release-commit`, and `trigger-releases` need no changes — their `needs` chains never contain a legitimately-skipped job. Tests pin the new truth tables for both jobs, mirroring the style #5169 used for `release-please`, and `_evaluate` now handles `always()`.
Caution
Merging this PR will automatically publish to PyPI and create a GitHub release.
For the full release process, see
.github/RELEASING.md.Release notes preview: keep this section in sync with the package
CHANGELOG.md. Publish reads the merged CHANGELOG viarelease.yml, not this PR description — keep them aligned anyway so the PR stays an accurate historical record for reviewers and anyone returning later.0.7.1 (2026-07-30)
Features
lc_versions.deepagents(#5158)Bug Fixes
read_filewindows (#5184)End release notes preview.
Note
A New Contributors section is appended to the GitHub release notes automatically at publish time (see Release Pipeline, step 2).