Update inotify to 0.10

[fornwall]

See the CHANGELOG.

[fornwall]

Hi @0xpr03, could you have a look at this PR?

[0xpr03]

Is there a strong reason to push for 0.10 ASAP ? I don't see any real reasons in their changelog.

[0xpr03]

In any case I'd like to land #549 first as you both interact with the CI and your changes are easier to rebase on top of that. The MSRV break will also make this part of #525.

[0xpr03]

Blocked by #549.
And we might want to look into re-using watches() for hot loops.

[0xpr03]

Thanks, I've added one comment regarding the watches() overhead.

[fornwall]

Is there a strong reason to push for 0.10 ASAP ? I don't see any real reasons in their changelog.

The main driver here is to avoid duplication - other crates in the ecosystem are using 0.10 (for instance https://gitlab.com/gilrs-project/gilrs), and there is a desire (or rule) in many projects to avoid pulling in multiple versions of the same crate.

So in general, unless there is a good reason, I think the latest released version of a crate should be used.

[fornwall]

Tested this a bit, and it seems we might need to adopt to: hannobraun/inotify-rs#190. EDIT: Done in 9f0c4d5

[fornwall]

Thanks, I've added one comment regarding the watches() overhead.

Thank you for the review! Addressed that one in b70b72b

[MarijnS95]

The main driver here is to avoid duplication - other crates in the ecosystem are using 0.10 (for instance https://gitlab.com/gilrs-project/gilrs), and there is a desire (or rule) in many projects to avoid pulling in multiple versions of the same crate.

Yeah, same for us, we'd love to see both crates in sync :)

[0xpr03]

Thanks, I got to merging the blocker and fixed one small readme formatting error while rebasing for (valid) CI results.

[0xpr03]

Now let's see, there is some hope I can get around to a new release this weekend, but no promises.