Automatic bumping of dependency version (using e.g. Dependabot) best practices

[killercup]

With dependabot we've recently gained a nice bot that can automatically open pull requests on Rust repositories and bump versions.

I'm currently of the opinion that this is best used on crates that mainly produce binaries, and only update the lockfile. Since this is also way to get notified about security updates in crates, it's may become an important tool for crates in "maintenance mode".

We should come up with a set of best practices around this.

Relevant discussion in cargo-edit: killercup/cargo-edit#224 (comment)

[epage]

I have some initial dependabot documentation and practices

Since then

• I've changed my default update schedule to once a month from once a week (too many serde releases)

I'm currently of the opinion that this is best used on crates that mainly produce binaries, and only update the lockfile. Since this is also way to get notified about security updates in crates, it's may become an important tool for crates in "maintenance mode".

There is a flag to set this but I tend to like having it handle "breaking" changes for me

• Helps me to know that one is available
• Not all breaking changes break everyone, sometimes the upgrade is free

Caveats for using this feature:

• accidentally upgrading rustc version: I've already documented the importance of verifying your oldest supported rustc version.
• Accidentally approving a breaking change if you have another crate in your API.

Any other caveats or concerns we should document or change our default recommendation?

[epage]

@killercup

a lot of projects might not appreciate pro-active version bumps that only end up being PRs that don't build and go stale/get closed

We should

• Ensure people know about the feature not to modify Cargo.toml and let people know of trade offs
• Ensure people know about the flag for non-root Cargo.toml
• Deviate bin/lib recommendations as needed

We should also see what works and doesn't with workspaces.

[killercup]

Link to discussion on Gitter (summarized by @epage above)