Prepare 0.5.10 release

[abonander]

I got lazy when I wrote the changelog for 0.5.8 and didn't list all the PRs, and some folks were disappointed that their PR wasn't listed. So listing all 31 for this release cycle!

[05storm26]

@abonander Oh, oh you have bumped up the indexmap version back to 1.7 from 1.6.2 ergo reverting this: #1501

This creates a dependency cycle bug: #1521

The bug is about the ahash dependency:
tkaitchuck/aHash#95

[05storm26]

@abonander Could you downgrade the indexmap dependency to 1.6.2 again? Or is there a specific reason why sqlx needs 1.7 instead of 1.6.2?

[abonander]

Damn it. I ran cargo upgrade which I think is from cargo-edit just to get various dependencies caught up.

Why hasn't that been fixed upstream yet?

[05storm26]

Its basically about wasm-bindgen and the maintainer @alexcrichton not having time for a major redesign :\

See this comment: tkaitchuck/aHash#95 (comment)

(and maybe also the 2 comments before it)

[abonander]

Yeah I just read back through the discussion. You'd think one of those other packages would have made a change to break the chain by now. Keeping a dependency pinned at a single version forever is not a solution.

[paolobarbolini]

Damn it. I ran cargo upgrade which I think is from cargo-edit just to get various dependencies caught up.

Honestly I wish that wouldn't be done. It forces downstream users to upgrade all of their indirect dependencies when in some cases there might be a reason to stay back and it creates merge conflicts when dealing with PRs or forks (which for example we have to deal with as we have a fork with PRs targeting 0.6.0 already merged)

[abonander]

@paolobarbolini yeah, to be fair I mostly did it just to head off any complaints about outdated dependencies. There's not exactly a checklist for doing releases of crates of this size. Someone should write one.

[05storm26]

@abonander Libs shouldn't need to worry about outdated dependencies because I think cargo uses the newest version that has the same major version as the specified one.

So writing 1.6.2 allows cargo to use 1.7 but not 2.1 for example.

Libs really shouldn't ever need to update their dependencies except for 2 cases:

• There is something in the 1.7 version that is not in 1.6.2 and you need to use it.
• There is a major version release of a dependency (like 2.0) and the community has started to migrate to that and you want your lib crate to also be compatible with that version and not needlessly use the old version.

If this is true cargo update really shouldn't even work for lib crates IMO. It should give some warning or something if run on a lib crate.

[paolobarbolini]

to be fair I mostly did it just to head off any complaints about outdated dependencies

I understand, I'm subscribed to some projects and there's always someone thinking that the way to upgrade patch versions of their indirect dependencies is by sending a PR.

Maybe there should be a CI job checking that the minimum versions still work, and just reply to complaints and PRs with instructions for cargo update.

I'm also part of deps.rs (this is what it looks like for sqlx https://deps.rs/repo/github/launchbadge/sqlx), which until recently would complain very aggressively when the allowed version range included an insecure version of a dependency, but even then people would most of the times ignore it. From this it seems acceptable not to bump dependencies in Cargo.toml, unless something very serious happened obviously.

[abonander]

It was cargo upgrade specifically, not cargo update.

And yes, I understand how dependency resolution in libraries works. For the record, this is the discussion I had in mind when I ran it: #1586 (comment)