I am a bit afraid that this could be a breaking change, as I am pretty sure the the value returned byzlibVersion() won't be exactly the same in all cases.

This mechanism is for the library to ensure that 1) everything was linked correctly and 2) the required features in zlib are supported. Generally that means that certain symbols are available that weren't in earlier versions. So the one failure mode I can see is ifflate2 is used with a much older system zlib, and that somehow causing e.g. linker issues.

I believe though that the symbols/functions thatflate2 uses in practice have been unchanged since at least the early 2000s? So I don't think this change is observable.

As far as I can see it's not something that's ever accessible externally, the version string is just accessed and passed into the function where in case of the original zlib, there is acheck whether the first byte matches with the internal version number and that the string pointer is notNULL so it shouldn't be any issue changing it.

The underlying zlib version isn't something that can be relied on in any case unless you control the full distrubution since e.g some linux distros like fedora swap out zlib for zlib-ng and debian (and by extension ubuntu)patches flate2 to remove all zlib variations and zlib-rs to only use system stock zlib.

Sounds good!

I think that, because zlib-rs is pre 1.0, we'll need to change the version bound to (to0.5, or perhaps even>=0.5 because having the C abi and not changing anything about that is kind of the point of that crate.)