# Batch Deps Upgrade > Batch all open Dependabot dependency upgrade PRs into a single PR Use when this capability is needed. - Skill: `tomevault-io/batch-deps-upgrade` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/batch-deps-upgrade` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/batch-deps-upgrade/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/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/xrpl4j --label dependencies --state open --limit 500 --json number,title,headRefName,body,url` Parse each PR to extract coordinates and versions. Maven Dependabot PRs come in two formats: - **Single-package PRs**: title is `Bump : from to ` — parse groupId, artifactId, old version, and new version from title - **Property PRs**: title is `Bump from to ` — the property name maps to a `` entry in `pom.xml` (e.g., `jackson.version`, `feign.version`) - **Grouped PRs**: title lists multiple packages — parse from PR body, which contains a structured list of package updates 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. Also note: Dependabot sometimes opens duplicate PRs for the same dependency across submodules (e.g., `xrpl4j-core/org.assertj-assertj-core-3.27.7` and `xrpl4j-integration-tests/org.assertj-assertj-core-3.27.7`). Deduplicate — if the version is managed centrally in the root `pom.xml` `` or ``, one update covers all submodules. Mark the duplicates as No-op (managed by root pom). ## Step 2: Apply 1. If a target branch already exists for this quarter's upgrades, work on that branch. Otherwise create a new branch from main: `deps/batch-deps-upgrade-YYYY-QN` (use current year and quarter). 2. Inspect the root `pom.xml` to determine where each dependency's version is controlled: - **Version property**: a `` entry like `2.14.0` — update the property value - **Direct version in ``**: a `` element — update it directly - **BOM import in ``**: a `` with `pomimport` — update its `` - **Maven plugin version**: in `` — update the `` element 3. Check for **compatibility constraints** before upgrading: - **Java version**: read `maven.compiler.source` from `pom.xml`. If a dependency's new version requires a higher Java version than the project's compiler source, mark it as Skipped immediately — do not attempt the upgrade. Known constraints: caffeine 3.x requires Java 11+, junit-bom 6.x requires Java 17+. - **API changes**: major version bumps may require source-level changes (e.g., changed APIs, removed methods, renamed classes). Flag these as needing extra validation. 4. Apply each upgrade by editing `pom.xml` directly. For version properties, use `mvn versions:set-property -Dproperty= -DnewVersion= -DprocessAllModules` as an alternative to manual XML edits — but verify the result looks correct before proceeding. 5. Run `mvn dependency:resolve -q` to verify the dependency graph resolves without conflicts after applying all changes. 6. Classify each Dependabot PR as: - **Upgraded**: version changed in pom.xml - **No-op**: version was already current or newer, or is a duplicate submodule PR covered by a root-pom change - **Skipped**: compatibility issue or unresolvable conflict ## Step 3: Validate Run the build and test suite in order: 1. `mvn clean install` - This compiles all modules, runs checkstyle, runs unit tests, and runs integration tests 2. If step 1 fails, **attempt to fix the breaking change with code modifications before rolling back**. Common patterns for Java/Maven: - **Removed or renamed API** (e.g., a method removed in a major version): update call sites to use the new API - **Changed constructor or builder pattern**: adapt usage to the new API - **Checkstyle violations from new code patterns**: fix the style issue - **Compile errors from changed generics or type parameters**: adjust the type annotations - **Breaking changes in BouncyCastle** (crypto library): the API often changes significantly between major versions — check migration notes - **JUnit 5 → 6 migration**: junit-bom 6.x requires Java 17+ (class file version 61.0) — skip unless the project has already raised its minimum Java version to 17 3. Only roll back and mark as Skipped if: - The fix requires a large-scale migration across many files - The upgrade is blocked by an incompatible transitive dependency you cannot resolve 4. If a failure persists after investigation, roll back the upgrade and mark it as Skipped. Re-run validation until green. ## Step 4: Generate Outputs Do NOT commit or create a PR. Instead, generate the following outputs for the human to use: 1. **Code changes note** — write a markdown file (`.claude/skills/batch-deps-upgrade/code-changes.md`) documenting every non-pom.xml source code change: what broke, why, and the minimal fix applied. 2. **Commit message** — output a concise commit message the human can copy-paste. Format: `chore(deps): quarterly batch dependency upgrade YYYY-QN` followed by a brief summary of upgrades, skips, and no-ops. 3. **PR description** — write a markdown file (`.claude/skills/batch-deps-upgrade/pr-description.md`) containing: - A summary section describing the batch upgrade - A "Superseded Dependabot PRs" table with columns: PR (linked), Package (`groupId:artifactId`), From, To, Status, MajorVersionUpgrade - Status values: Upgraded, No-op (reason), Skipped (reason: compatibility issue / build failure: error) - MajorVersionUpgrade: `No` if the major version number did not change. Otherwise `Yes` plus a link for each major version crossed — link to the package's Maven Central release notes, GitHub releases page, or CHANGELOG.md. Verify each link returns HTTP 200 before including it. - 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 (`groupId:artifactId`), #B (`groupId:artifactId`), ..." — these stay open so Dependabot keeps rebasing them. --- > Source: [XRPLF/xrpl4j](https://github.com/XRPLF/xrpl4j) — distributed by [TomeVault](https://tomevault.io).