update dependencies

[fdncred]

Update dependencies, specifically rusqlite

[sholderbach]

Sorry @fdncred, but removing the patch version from the specifier doesn't help long term.

This might be a misconception about the format but the versions x.y.z without restricting symbols allow all more recent semver compatible versions.

Removing the info which patch versions were tested, can be counterproductive in rare circumstances, where something might have been broken before that patch and we never tested it, but the version specifier let's cargo decide based on what is available on the system or with other dependencies in the crate graph.

So for just pullling in patches without necessary improvements cargo update to update Cargo.lock should suffice.
And if there are clear improvements we want, pinning to that release in Cargo.toml should be the course of action.

[fdncred]

I'm not sure what to say @sholderbach. You clearly know this better than I so I won't dispute the efficacy with you. What pushed me to do this was that I just hate the incessant task of tracking down which is the latest patch version for each crate in each cargo.toml to make sure we're benefiting from the latest and greatest changes. Where there were current issues, I left them as-is. I'm aware that there could be breaking changes to this strategy, but I figured those rare moments would fall out in the tests and we could decide what to do then.

[sholderbach]

I think on the side of the nushell binary that is not so much of a problem (as we control the whole set of allowable dependencies and can effectively test with both the most recent compatible versions and the lockfile). The danger zone is more pressing for outside users of our libraries were we can not guarantee that they don't have a lockfile (or restrictive version specifier) which would use a really old version we never checked.

For libraries the consuming binaries will pull in the most recent version anyways. And for binaries it is more an act of from time to time running cargo update to get the latest and hopefully greatest for free (or with cargo install).

Did we run into issues with the dependabot?

For the deep dive into the trickiness around breakages due to upstream versions I probably have to refer to Jon Gjengsets video on crate CI setup (had laid out the take-aways around version specs in nushell/nu-ansi-term#27 (comment))

[fdncred]

I thought cargo update would only update the lock file up to the version you had specified in the cargo.toml. e.g. if you have "crate_name = 1.1.1" and you do cargo update I thought it would only update the cargo.lock file up to version 1.1.1 even if version 1.1.2 was released/published. Am I understanding that wrong?

[sholderbach]

I thought cargo update would only update the lock file up to the version you had specified in the cargo.toml. e.g. if you have "crate_name = 1.1.1" and you do cargo update I thought it would only update the cargo.lock file up to version 1.1.1 even if version 1.1.2 was released/published. Am I understanding that wrong?

1.1.1 will be the minimum version and it can pick up both 1.2.0 or 1.1.5 if they would be the most recent. (For 0.2.0 it would only pick up 0.2.1 and not 0.3.0)