Skip to content

chore(deps): patch-level dependency refresh (2026-09) - #3

Open
petronijus wants to merge 1 commit into
mainfrom
chore/deps-2026-09
Open

chore(deps): patch-level dependency refresh (2026-09)#3
petronijus wants to merge 1 commit into
mainfrom
chore/deps-2026-09

Conversation

@petronijus

Copy link
Copy Markdown
Owner

Monthly automated dependency maintenance. update_policy: patch.

Bumped

file package old → new why
mcp_server/requirements.lock sse-starlette 3.4.8 → 3.4.11 transitive, via mcp

requirements.lock is unchanged — all 29 pins are already at the newest
patch of their current minor series. I checked every pin against PyPI rather
than assuming; nothing else had a patch available.

Gates

gate result
build n/a (no build step)
test n/a — repo has no test suite
lint n/a (not configured)
lock installs --require-hashes (py3.11, Dockerfile base)
mcp_server/server.py imports against the new resolve

Code changes for breaking APIs

None — patch-level only, no API surface moved.

Notes for the reviewer

  • Lockfiles were regenerated with the same resolver settings scripts/deps-lock.sh
    uses (uv pip compile --python-version 3.11 --generate-hashes --no-header),
    but scoped with --upgrade-package sse-starlette==3.4.11 so the diff is exactly
    three lines and no unrelated pin or hash churns. Neither .lock was hand-edited.
  • The loose floors in requirements.txt / mcp_server/requirements.txt were not
    touched: nothing needed a higher floor, and mcp>=2.0.0,<3 stays deliberately
    bounded per the note in projects.yml.
  • Verification ran against mcp_server/requirements.lock only, since that is the
    only file this PR changes.

🤖 Generated with Claude Code

Monthly maintenance sweep, update_policy=patch.

mcp_server/requirements.lock:
  sse-starlette 3.4.8 -> 3.4.11  (transitive, via mcp)

requirements.lock: no change — every pin is already at the latest
patch of its current minor series.

Regenerated with scripts/deps-lock.sh's resolver settings
(uv pip compile --python-version 3.11 --generate-hashes), scoped to a
single package so no unrelated pin or hash churns.

Verified: lock installs clean under `pip install --require-hashes`
(python 3.11, the Dockerfile base) and mcp_server/server.py imports.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants