setup dependabot

[jcornaz]

Hi,

following up on #116, I propose to configure dependabot, a GitHub service that watches the dependencies and opens pull requests, when it finds newer versions to be available.

Here is an example of a PR opened by dependabot: https://github.com/jcornaz/heron/pull/169

And, the github documentation about dependabot: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/about-dependabot-version-updates

This is merely a suggestion. If you are not interested, you can simply close this PR ;-)

[est31]

There are a couple problems with dependabot, especially its default settings. dependabot is per default set to update a dependency immediately after its release. In most settings, this is not needed, pollutes the git history, and causes build times to increase.

Also, dependabot often updates the version requirement in Cargo.toml, which bases on a misunderstanding what it is: it's a requirement, that is, cargo by default downloads newer compatible versions if they are available. If they are not, it requires a manual intervention because the API might have broken, at which point one needs manual intervention anyways.

cargo-udeps is a low-traffic repository, but if it had active feature development with people following the master branch, then too regular updates would disrupt the users all the time, requiring them to rebuild the entire chain of dependencies because one dependency very high up the chain had an update that fixed a typo in one of the docs. dependabot was originally developed for interpreted languages, where an update of a dependency causes no overhead, but for compiled languages it's the wrong tool, especially at these settings.

I'm not against doing updates, they should absolutely be done. But it's better to do them more rarely, like every couple of weeks for a low change traffic project like cargo-udeps.

Right now, for cargo-udeps, I follow a 6 week schedule, which releases a new version after a new cargo update came out, as cargo is the principal dependency. At this opportunity I also run cargo update, as well as cargo-outdated to look if the version requirements are compatible with the latest released version of a crate. That way, I collect the updates to one regular "update everything" event.

Most of this stuff can be changed by settings, but I'm not sure if a "run this every Rust release" interval can be set yet by dependabot. Anyways, a release requires more manual changes than just the dependency update, and cargo update && git add . && git commit isn't that hard.

[jcornaz]

I understand your position. even it I don't really agree (notably, because frequency can be tuned to weakly or monthly, and because it does nothing more than opening a pull request. You can merge whenever you please and amend however you like).

But as I said, this was merely a suggestion. I understand if you are not interested, and you can feel free to close the PR ;-)

[est31]

Okay, I'll close this then.