fix(deps): set rangeStrategy widen for all pep621 packages

[olivermeyer]

Why?
Renovate was generating bump PRs (e.g. >=23.0.1,<24 → >=25,<26 for pyarrow, >=1.19.0,<2 → >=2.3,<3 for mypy) instead of widening the existing range. For a published SDK, bumping discards backward compatibility with older installed versions that users may have pinned.

How?
Adds a packageRule scoped to the pep621 manager with rangeStrategy: widen, covering all update types including major. Renovate will now extend the upper bound of existing ranges rather than replacing them (e.g. >=23.0.1,<26 instead of >=25,<26). PRs #697 and #648 can be rebased to pick up the corrected behaviour.

[claude]

PR Review: Renovate Range Strategy Configuration ✅

Summary

This PR correctly configures Renovate to use rangeStrategy: widen for all pep621 packages, addressing a critical issue for this published SDK where dependency bumps were breaking backward compatibility.

---

Analysis

Problem Context

Examined the referenced PRs that demonstrate the issue:

• PR fix(deps): update dependency pyarrow to v25 #697: pyarrow updated from >=23.0.1,<24 → >=25,<26 (replaces range)
• PR chore(deps): update dependency mypy to v2 #648: mypy updated from >=1.19.0,<2 → >=2.3,<3 (replaces range)

The default replace/bump strategy discards the lower bound, breaking compatibility for users with older installed versions. For a published SDK on PyPI, this is problematic.

The Solution

With rangeStrategy: "widen", Renovate will instead:

• pyarrow: >=23.0.1,<24 → >=23.0.1,<26 ✅ (preserves v23-24 compatibility)
• mypy: >=1.19.0,<2 → >=1.19.0,<3 ✅ (preserves v1-2 compatibility)

This is the industry best practice for library dependencies (source).

---

Review Findings

✅ Strengths

1. Correct Strategy for a Library

   • This is a published SDK (name = "aignostics" in pyproject.toml)
   • widen strategy maintains backward compatibility with users' installed versions
   • Prevents breaking changes in dependency ranges

2. Well-Documented Configuration

   "description": "Widen version ranges for pep621 packages rather than replacing them, preserving backward compatibility with older installed versions"

   Clear rationale that future maintainers will understand

3. Proper Scope

   • Uses matchManagers: ["pep621"] (correct for pyproject.toml)
   • Applies to all update types (major, minor, patch)
   • Positioned as first rule in packageRules array (acts as default)

4. No Conflicts

   • The runtime-critical packages rule (nicegui, fastapi, etc.) doesn't specify rangeStrategy, so it correctly inherits widen
   • vulnerabilityAlerts can override if needed for security fixes
   • Lock file maintenance is unaffected

5. Conventional Commit ✅

   fix(deps): set rangeStrategy widen for all pep621 packages
   

   Follows conventional commits standard

---

CRITICAL CHECKS

✅ Test Markers

• N/A: Configuration file change, no tests modified

✅ Test Coverage

• N/A: Configuration file change, no code modified

✅ Code Quality

• JSON Syntax: Valid ✅
• Configuration Schema: Matches Renovate schema ✅

✅ Architecture Compliance

• N/A: Infrastructure configuration change

✅ Breaking Changes

• None: This improves dependency management without breaking existing behavior
• Future Renovate PRs will widen ranges instead of replacing them

---

Questions Addressed

Q: Does this affect security vulnerability updates?
A: The vulnerabilityAlerts configuration can override rangeStrategy if aggressive bumping is needed for security fixes. The current setup (vulnerabilityAlerts.automerge: true) will still work, but will widen ranges. If needed, you can add rangeStrategy: "bump" to the vulnerabilityAlerts config to override for security-only updates.

Q: Will this apply to major version updates?
A: Yes. rangeStrategy applies to all update types (major, minor, patch) unless overridden in specific package rules.

Q: What about the runtime-critical packages rule?
A: Those packages (nicegui, fastapi, httpx, etc.) don't specify their own rangeStrategy, so they'll inherit widen from this default rule, which is correct behavior.

---

Recommendations

Optional Enhancement (Non-Blocking)

Consider adding an explicit override for security vulnerability alerts if you want aggressive bumping for security fixes:

"vulnerabilityAlerts": {
  "enabled": true,
  "automerge": true,
  "rangeStrategy": "bump"
}

This would:

• Normal updates: widen ranges (preserve compatibility)
• Security updates: bump to latest (prioritize security)

However, this is not required for this PR — the current configuration is correct and safe.

---

Verdict

✅ APPROVE — This is a focused, correct configuration change that follows best practices for published libraries. The widen strategy is the appropriate choice for an SDK to maintain backward compatibility with users' installed dependency versions.

Impact: PRs #697 and #648 can be rebased to pick up the corrected behavior.

---

Verdict: ✅ claude:review:passed

---

View job run

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.
see 2 files with indirect coverage changes

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud