# Batch Deps Upgrade > Batch all open Dependabot dependency upgrade PRs into a single PR - Skill: `xrplf/batch-deps-upgrade` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add xrplf/batch-deps-upgrade` - Raw SKILL.md: https://api.skillmd.com/api/skills/xrplf/batch-deps-upgrade/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: xrplf (https://skillmd.com/u/xrplf) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/xrplf/batch-deps-upgrade --- Batch all open Dependabot dependency upgrade PRs into a single PR for this repository. ## Step 1: Discover Run: gh pr list --repo XRPLF/xrpl-py --label dependencies --state open --limit 500 --json number,title,headRefName,body,url Parse each PR to extract package names and versions. Dependabot PRs come in two formats: - **Single-package PRs**: title is `bump from to ` — parse from title - **Grouped PRs**: title is `bump and ` with no versions — parse from PR body, which contains a structured list of package updates with version ranges If any PR can't be parsed from either title or body, flag it for manual review. Build a table of all proposed upgrades. Report the table to the user before proceeding. ## Step 2: Apply all upgrades 1. Create a branch from main: `deps/batch-deps-upgrade-YYYY-QN` (use current year and quarter) 2. Check for **dependency conflicts** before upgrading. For each proposed upgrade, review `pyproject.toml` constraints and run `poetry show ` to check if any other dependency pins a version range that would block the upgrade. Mark conflicts as Skipped (dependency conflict:
) and do not attempt them. 3. For each remaining dependency, apply the upgrade: - **Direct deps** (listed in `pyproject.toml` under `[tool.poetry.dependencies]` or `[tool.poetry.group.dev.dependencies]`): update the version constraint in `pyproject.toml` to the new version using caret (`^`), then run `poetry update `. Always update `pyproject.toml` for direct deps — even if the current constraint already allows the new version — so the pinned minimum stays current. - **Transitive deps** (not in `pyproject.toml`): run `poetry update ` to update within the existing constraint range 4. After all upgrades are applied, run `poetry lock` to regenerate `poetry.lock`. **Do NOT delete `poetry.lock` and regenerate from scratch**. 5. Run `poetry install` to sync the virtual environment. 6. Diff `pyproject.toml` and `poetry.lock` against main to classify each Dependabot PR as: - Upgraded: version changed - No-op: version was already current or newer 7. If any upgrade changes the public API of the library (new errors, changed return types, removed functionality) and results in a breaking change, add an entry under `## [Unreleased]` in `CHANGELOG.md`. 8. Verify completeness: every PR from Step 1 must have a status (Upgraded, No-op, or Skipped). If any PR is unaccounted for, stop and report it before proceeding. ## Step 3: Validate Run the **full validation suite across all Python versions** from the CI matrix. Repeat until everything passes. ### Determine Python versions Read each workflow file under `.github/workflows/` to determine the Python versions used: - `.github/workflows/unit_test.yml` — the `unit-test` job uses a matrix of Python versions; the `lint-and-type-check` job uses a single Python version (not a matrix) - `.github/workflows/integration_test.yml` — the `integration-test` job uses a matrix of Python versions - `.github/workflows/faucet_test.yml` — the `faucet-test` job uses a matrix of Python versions Extract the exact Python versions from each workflow's `matrix.python-version` array (or the `PYTHON_VERSION` env var for lint). These versions are the source of truth for validation. ### Switching between Python versions To switch Python versions for testing, use `pyenv` and `poetry`: ```bash pyenv install # install if not already present pyenv local # set the local Python version poetry env use python # point poetry to the correct interpreter poetry install # reinstall deps for this interpreter ``` Replace `` with the target version (e.g. `3.10`, `3.11`, `3.12`, `3.13`, `3.14`). After running all tests for one version, repeat these steps to switch to the next. ### Validation order Run validation **in parallel across all Python versions** from the unit test matrix to speed things up. For each Python version, create a separate working directory (e.g. using `git worktree` or by spawning parallel agents) so that each version's virtual environment does not interfere with the others. For each Python version, run the following in order: 1. **Lint and type-check** (only on the single lint Python version from the `lint-and-type-check` job): ```bash poetry run poe lint poetry run mypy --strict --implicit-reexport xrpl ``` 2. **Unit tests**: ```bash poetry run poe test_unit poetry run coverage report --fail-under=85 ``` 3. **Integration tests** (requires a single shared xrpld Docker container — start it once before running integration tests for any Python version): - Pre-run cleanup: `docker rm -f xrpld-service 2>/dev/null || true` - Start the container: ```bash docker run \ --detach \ --publish 5005:5005 \ --publish 6006:6006 \ --volume "$PWD/.ci-config/:/etc/xrpld/" \ --name xrpld-service \ rippleci/xrpld:develop --standalone ``` - Wait for port 6006 with a bounded timeout: ```bash SECONDS=0 until nc -z localhost 6006 || [ $SECONDS -gt 120 ]; do sleep 2; done if ! nc -z localhost 6006; then echo "Error: xrpld did not start within 120s" docker logs xrpld-service exit 1 fi ``` - Run for each Python version: ```bash poetry run poe test_integration poetry run coverage report --fail-under=70 ``` - Stop container after all versions complete: `docker logs xrpld-service && docker stop xrpld-service` 4. **Faucet tests**: ```bash poetry run poe test_faucet ``` Collect results from all parallel runs. All Python versions must pass. ### Handling failures If any step fails, **attempt to fix the breaking change with code modifications before rolling back**. Common patterns: - **Type annotation changes**: newer versions of type stubs or mypy may require updated annotations. Fix the annotations. - **Deprecated API removals**: if an upgraded dependency removes a previously deprecated function, update calls to use the replacement API. - **Import path changes**: some packages reorganize their module structure on major bumps. Update import statements. - **Test compatibility**: if a test utility changes behavior (e.g., aiounittest, coverage), update test configuration or code accordingly. Only roll back and mark as Skipped if: - The fix requires a large-scale migration across the codebase - The upgrade is blocked by an external dependency constraint you cannot update If a failure is traced to a specific dependency upgrade, revert that upgrade in `pyproject.toml`, re-run `poetry lock && poetry install`, mark it as Skipped, and re-run validation until green. ## Step 4: Generate Outputs After all upgrades are applied and validation passes, generate the following outputs: ### 4a. Code changes note Write `.claude/skills/batch-deps-upgrade/code-changes.md` documenting every non-`pyproject.toml` source code change, explaining what broke, why, and the minimal fix applied. ### 4b. PR description Write `.claude/skills/batch-deps-upgrade/pr-description.md` following the repo's PR template (`.github/pull_request_template.md`): - For "High Level Overview of Change", summarize the batch upgrade. - For "Context of Change", explain that this batches Dependabot PRs to reduce merge noise. - For "Type of Change", determine dynamically: - Check "Breaking change" ONLY if any upgrade visibly changes the library's public API (e.g., error messages, return types, removed functions). This aligns with whether a `CHANGELOG.md` entry was added in Step 2.7. - Otherwise, do not check any Type of Change — dependency upgrades are maintenance and don't fit "Refactor" (which means restructuring code without behavior change). Note in the PR body that the upgrade is maintenance. - For "Did you update CHANGELOG.md?", check "Yes" if an entry was added, otherwise check "No, this change does not impact library users". - Include a "Superseded Dependabot PRs" section with a table: PR (linked), Package, From, To, Status, MajorVersionUpgrade - Status values: Upgraded, No-op (reason), Skipped (dependency conflict / CI failure: error) - MajorVersionUpgrade: `No` if the major version number did not change. Otherwise `Yes` plus a link for each major version crossed. For example, 1.x → 3.x yields `Yes ([v2](url), [v3](url))`. Each link should point to the package's release notes or changelog for that major version. Verify each link returns HTTP 200 and has meaningful content (e.g., `curl -sL -o /dev/null -w "%{http_code}" `); if a package doesn't publish per-version GitHub releases, fall back to the CHANGELOG file or the closest valid release tag. - For every **major version upgrade**, add a "Major version upgrade notes" section below the table. For each major-version package, include: - A link to the release notes - A brief summary of key changes (breaking changes, deprecations, new features) - An explanation of why no code changes were required, OR a summary of the code changes that were made. This helps reviewers understand the impact without having to read the full release notes themselves. - Closing instructions with two paragraphs: 1. "After merging, close the following superseded PRs (Skipped ones remain open for future handling): #X, #Y, #Z" — list only Upgraded and No-op PRs. 2. "The following PRs were Skipped and should remain open: #A (package-a), #B (package-b), ..." — annotate each with the package name. These stay open so Dependabot keeps rebasing them.