A less aggressive dependabot

[kneth]

Currently, dependabot is creating PRs faster than we can review and merge. To make dependabot less agresive, we need to consider the following to settings

• schedule
• versioning-strategy

[amotl]

Hi. Please don't adjust the schedule. Having daily runs gives us the chance to react early to relevant changes, not only after a month when more users might be impacted from something that went south.

Tuning the test frequency down would defy this very important purpose of the repository. If you don't like any version bumping policy currently applied, please adjust that, or migrate away from Dependabot.

Dependabot was starting to go crazy about bumping lower bound version numbers only recently. Maybe this is what you are referring to as "aggressive"?

• Dependabot tries to bump min version to latest release dependabot/dependabot-core#14798 (comment)

Upstream people are working on improving the situation:

• feat(python): add widen_ranges support for setup.py and setup.cfg dependabot/dependabot-core#14825

Otherwise, we can also switch from Dependabot to Renovate, which successfully accepts the "widen" version bumping strategy.

[amotl]

Dependabot was starting to go crazy about bumping lower bound version numbers only recently.

In this spirit, please also close all those PRs. They are wrong.

[amotl]

Otherwise, we can also switch from Dependabot to Renovate, which successfully accepts the "widen" version bumping strategy.

This will lead to less Dependabot traffic as long as Dependabot does not re-adopt the "widen" policy. For a blueprint, see CTK's renovate.json5 configuration file.

[amotl]

Currently, dependabot is creating PRs faster than we can review and merge.

Holding up to a diligent daily routine to process all signals is crucial. Otherwise, all the benefits like catching regressions in CrateDB and reacting early to relevant hiccups will become moot. If you start training, possible drag will quickly go away and the benefits will shine through. You can also use the venerable build status page as a tool for this purpose.

[amotl]

Hi. This spot is another good example why scheduling nightly runs and Dependabot on a daily interval is advisable to catch any kinds of regressions through package updates or other moving targets.

• Python/SQLAlchemy: Statement exceeds statement_max_length sqlalchemy-cratedb#284

[amotl]

Hi again,

the widen version bumping strategy causes significantly less traffic, and also provides perfect DWIM for us ¹. This patch suggests another proposal to bring back the widen version bumping strategy after Dependabot stopped providing it for pip requirements, by migrating to Renovate.

• CI: Migrate from Dependabot to Renovate #1841

With kind regards,
Andreas.

Footnotes

1. The reason is we don't want to increase the lower boundaries of version range constraints too much, in order to provide and validate solutions for a wide audience of people. Quite a bunch of them are sometimes constrained to older software releases more often than not. ↩