fix(renovate): major-only Python lower-bound bumps + 30-day major grace#344
Conversation
PR #343 made `rangeStrategy: bump` apply to every release for pep621/pip_requirements/pip_setup/poetry/pipenv, so the `>=` floor moved on minor and patch releases too. That floods consumer repos with PRs that only re-state the floor at the latest pinpoint version — no security or compatibility signal behind them. Two changes: 1. 30-day grace period for any major-version update, org-wide. Gives upstream ecosystems time to surface breaking regressions before we adopt. CVE bumps still bypass via `vulnerabilityAlerts` (0 days). 2. Restrict the Python `>=` bump rule to `matchUpdateTypes: ["major"]`. Minor/patch updates now fall back to Renovate's default `replace` strategy, which no-ops when the existing range already satisfies the new version — exactly what we want for security/compatibility floors. After this, Renovate still produces `>=N.M.P` (e.g. `>=1.16.1`) on major bumps. Follow-up: a reusable normalization workflow that rewrites those to `>=N.0.0` so floors only express the major version.
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request refines the Renovate configuration to improve the quality and timing of dependency update PRs. By implementing a 30-day grace period for major versions and limiting automatic lower-bound floor bumps to major releases only, the changes reduce noise from minor/patch updates while ensuring major version transitions are handled with more caution. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. The major version waits a while, / To keep the codebase free of guile. / No minor bumps to flood the queue, / Just stable paths for all of you. Footnotes
|
The bump rule now states the full policy: - Default: floors are `>=N.0.0` (major only). - CVE exception: pin to the OLDEST secure version (not latest) and document every CVE in an inline comment block above the floor. - Normalizer must preserve floors preceded by such a comment block. Canonical pattern lives in mlx-benchmarks/space/requirements.txt (pyarrow, pillow, orjson, idna).
* fix(deps): floor huggingface-hub at major-only (>=1.0.0) Renovate PR #56 merged with `huggingface-hub>=1.16.1`. Per the new lower-bounds policy (JacobPEvans/.github#344), `>=` floors should express the major version only. Rewrite to `>=1.0.0`. Other security-fix floors in this file (pyarrow, pillow, orjson, idna) intentionally pin at the CVE-fix patch version per the inline comment and are left untouched. * fix(deps): align pyproject.toml + uv.lock huggingface-hub floor to >=1.0.0 Addresses gemini-code-assist review on PR #60. The space/requirements.txt fix to `>=1.0.0` left pyproject.toml at `>=0.23` and the uv.lock specifier matching it, creating cross-file drift. All three now express the major-only floor consistently.
1 participant
Summary
minimumReleaseAgefor any major-version Renovate PR. CVE bumps still bypass via the existingvulnerabilityAlerts0-day path.>=lower bounds on every release #343rangeStrategy: bumprule for pep621/pip_requirements/pip_setup/poetry/pipenv tomatchUpdateTypes: ["major"]. Minor/patch updates fall back to Renovate's defaultreplace, which is a no-op when the existing range already satisfies the new version — so no more floor-bump PRs for non-major releases.Why
PR #343 made every Python release (including minor/patch) bump the
>=floor, producing PRs likehuggingface-hub: >=0.23 → >=1.16.1(mlx-benchmarks#56) andgoogle-adk: >=0.5.0 → >=2.0.0(mlx-benchmarks#57). The user feedback: floors should express a security/compatibility major only, and PRs should not open for minor/patch floor moves. Also, all major-version updates should get a 30-day grace so upstream regressions surface before adoption.What is NOT in this PR
Renovate will still write
>=N.M.Pon a major bump natively (e.g.>=1.16.1, not>=1.0.0). Rewriting the floor format to>=MAJOR.0.0requires a post-PR workflow that pushes a signed fixup commit to the Renovate branch — that is worth its own focused PR with the App-token signing path. Tracked as a follow-up issue.Test plan
>=N.M.Pfloor, and only after at least 30 days from release.vulnerabilityAlerts.minimumReleaseAge: 0 daysunchanged).