Any particular reason to target 1.26 not 1.28 of Tokio in this? Perhaps it wasn't released

@willstott101, yes, 1.26 was the latest version when I submitted this PR, there is no reason not to bump it again.

Since this is a semver change can you bump the version number up?

@cetra3, it's a minor version bump, right? I don't think the public API has changed.

I've split this PR into separate commits and bumped the minor version

@bemyak the version of zmq has had a major revision in this PR, from 0.9 to 0.10, so I would consider this semver breaking. It's not that it's a big issue, just need to bump to 0.4.0

zmq = ">=0.9.2" already pulled in 0.10 for us I think anyway, not sure a bump here would really reflect much in terms of stability, I guess it would cause a project which had a cargo lock from before 0.10 to now pull in 0.10 ... 🤷 you're probably right, worth bumping here too

OK, bumped it to 0.4.0

@bemyak For semver versions in rust < 1.0.0 i.e, 0.1 0.2 etc.. the minor version is treated as a major version & so something like >= 0.9.2 will only include 0.9.x versions

@cetra3, right. I've rewritten the commit message to remove the confusion.

Also >= is the default Cargo behavior:

The string "0.1.12" is a version requirement. Although it looks like a specific version of the time crate, it actually specifies a range of versions […]

Here are some more examples of version requirements […]

0.2.3  :=  >=0.2.3, <0.3.0

Is there anything else I can do here?

Thanks! I've published this as 0.4.0