Respect SemVer as Cargo understands it

[Dekkonot]

Howdy,

A project I maintain uses notify v4.0, which depends upon both winapi v0.3 and (through a dependency) winapi-util v0.1. You can see a rough graph here:

notify v4.0.*
├── walkdir v2.4.*
│   ├── same-file v1.0.*
│   │   └── winapi-util v0.1.*
│   └── winapi-util v0.1.*
└── winapi v0.3.*

During dependency resolution, Cargo "uses the convention that only changes in the left-most non-zero component are considered incompatible" as defined here. So since this crate is in 0.1.Z, any change to Z is considered compatible as long as the minor version remains 1.

Despite this convention though, v0.1.7 and v0.1.8 were breaking because they altered compatibility. This violates Cargo's SemVer usage, which impacted our project. Based on some searching, I believe this also impacted cargo-watch. One must imagine it is similarly impacting every crate that uses notify v4.0, but I haven't checked.

While you're very much allowed to do whatever you want pre-1.0.0, I would very much appreciate not having to catch changes like this. Please respect Semver as Cargo uses it.

[BurntSushi]

Ummm... okay... Can you please say what the specific incompatibility is? If you're going to say that I broke semver then please tell me what I did. Because it's not obvious to me. You linked to issues, but none of them obviously point to winapi-util?

[Dekkonot]

So, I'd like to apologize for this. I was juggling a lot of details at once so I wasn't as thorough with this as I should've been. I was able to solve the type mismatch users started reporting by pinning winapi-util to version 0.1.6, which lead me to believe this crate was the problem. I've been burnt by crates disobeying semver before so I was made a judgement call without looking too much closer. That was stupid of me.

After giving it yet more inspection, it turns out that winapi-util is responsible indirectly. Up until 0.1.7, it was enabling several features in winapi. It turns out that some of these features are required by notify to function, but they were never enabled by notify. The result is that when winapi-util updated it caused notify to no longer have the features of winapi it needed, which breaks compilation. This is the 'incompatibility' I noticed.

I... will be frank and say I didn't know this was an issue that could even happen. A crate relying upon features that it doesn't have enabled because a downstream dependency happens to enable them is scary. I'm going to open an issue for Notify, since it's really their fault. I'm very sorry for the inconvenience this caused.

[BurntSushi]

Ah yeah, that makes sense. The same thing happened when I put out a new release of regex-syntax about a year ago. It turned out that tracing-subscriber was implicitly relying on features of regex-syntax to be enabled through an intermediate dependency. There is some discussion there, but the conclusion as far as I can tell is that there is no real way to detect this. But the blame is, as you point out, certainly on the incomplete dependency specification.

winapi-util did indeed used to use winapi. But I was careful in the API design of this crate to avoid making winapi a public dependency. Which is why swapping it out for windows-sys should not have been a breaking change.

[BurntSushi]

Ref notify-rs/notify#601