To address the issues Dependabot is complaining about. Assuming tokio is important enough to the Rust ecosystem that they conform to semantic versioning stuff and this change is benign. Can roll back if there are any issues. Mostly just wanted to do this because I've been getting a bunch of emails about this.
Details
Details
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- master
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| services/backup/old/blob_client/Cargo.toml | ||
|---|---|---|
| 9 | I would prefer to keep this as MAJOR.MINOR. The reason being that cargo already does "get me next semver compatible version". By including a patch version, you are pinning it to the latest 1.23.x (we won't get 1.24.2, which is the latest). For executables, just the lock file really matters. http://aturon.github.io/tech/2018/07/25/cargo-version-selection/ | |
Comment Actions
Responding to @jon's comment and re-requesting review
| services/backup/old/blob_client/Cargo.toml | ||
|---|---|---|
| 9 | Hm, looks like it's still being resolved to 1.24.2 so I think it's going up to to MAJOR regardless of whether we specify PATCH?  1.23.1 is the earliest version that appears to resolves all the "security issues" flagged by Dependabot, so thought setting that explicitly might be good? Can change this to 1.23 if that's more idiomatic (looks like we're doing MAJOR.MINOR most places?). | |
| services/backup/old/blob_client/Cargo.toml | ||
|---|---|---|
| 9 | 1.23 := >=1.23.0, <2.0.0 In this case, both will resolve to 1.24.2. I don't feel strongly about this, but just visually it'd be nice to be consistent | |