Release 0.22 build from cargo fails after the release of 0.23

[tkasu]

I'm having problems building my project that is using release 0.22.

It seems that problems started after the release of rust-rdkafka 0.23 and rdkafka-sys 1.3.1.

   Compiling rdkafka-sys v1.3.1
  ...
   Compiling rdkafka v0.22.0
error[E0425]: cannot find function `primitive_to_rd_kafka_resp_err_t` in crate `rdsys`
   --> /Users/tkasu/.cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/rdkafka-0.22.0/src/client.rs:411:22
    |
411 |     let err = rdsys::primitive_to_rd_kafka_resp_err_t(err)
    |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `rdsys`

Release 0.22 is fetching rdkafka-sys 1.3.1 from which the function primitive_to_rd_kafka_resp_err_t has been removed.

[benesch]

That's unfortunate. Perhaps we need to be using strict version requirements in rdkafka. For now you should be able to work around the issue by adding a strict dependency on the correct version of rdkafka-sys to your project:

rdkafka = "0.22.0"
rdkafka-sys = "=1.2.2"

Alternatively perhaps we need to be bumping the major version of rdkafka-sys whenever we release a new version, since most versions involve semver breaking changes—but then we'd lose the parity with upstream's versioning. @fede1024 do you have thoughts?

[ghost]

@benesch Why don't you use tilde requirements to specify rust-rdkafka's dependency on rdkafka-sys?

This way you should be able to prevent minor version upgrades.

[tkasu]

@benesch thanks that works! Nevertheless, if this could be handled in rdkafka's dependencies it could potentially help at least new rustaceans like me in the future =).

[benesch]

@benesch Why don't you use tilde requirements to specify rust-rdkafka's dependency on rdkafka-sys?

I'm worried that's not sufficient! I'm not sure rdkafka upstream adheres to semver.

[benesch]

@benesch thanks that works! Nevertheless, if this could be handled in rdkafka's dependencies it could potentially help at least new rustaceans like me in the future =).

Yes, absolutely! Thanks for raising the issue. I'll leave this open until it's sorted out on our end.

[benesch]

Ok, I think the solution here is to allow rdkafka and rdkafka-sys to be selected independently. If we make rdkafka-sys properly follow semver, then rdkafka just needs to express the minimum version of rdkafka-sys that it is compatible with, and we should be good to go.

#234 starts us down that road.

[jan-auer]

Once #234 is released, would it be possible to release 0.22.1 that pins to rdkafka-sys 1.2.2? That way projects stuck on futures 0.1 can still run cargo update.

[benesch]

Yeah, that's not a bad idea. Ideally we'd yank 0.22.0, but that might be unnecessarily disruptive.

[jan-auer]

Ideally we'd yank 0.22.0, but that might be unnecessarily disruptive.

Agreed, since there might be repositories with lockfiles checked in that still work (like ours).

[benesch]

Agreed, since there might be repositories with lockfiles checked in that still work (like ours).

As I understand it, yanking doesn't prevent existing lockfiles from downloading that crate! It just prevents future folks from picking up the version via cargo update.

[benesch]

Ok, thanks to @fede1024, there's a release of 0.22.1 that pins to rdkafka-sys 1.2.2. Thanks for reporting, and sorry about the breakage.

Going forward, the new versioning scheme introduced in #240 ensures both rdkafka and rdkafka-sys follow semver and will allow mixing and matching versions of rdkafka/rdkafka-sys, semver permitting.