coordinated openssl version?

[ArtemGr]

So, when one project uses a crates version of openssl and another uses a git version, the build using both projects is broken. When one project uses an upstream version and another uses a fixed version (blackbeam/rust-mysql-simple@06edff7), the build using both projects will be broken very soon.

How do we coordinate this?

rust-lang/cargo#1006 will tell us about the issue but it's little help if the issue will resurface every time somebody updates the version in one of the projects.

I'm going to open this bug in multiple projects:
blackbeam/rust-mysql-simple#7
hyperium/hyper#175

[sfackler]

I'm following semantic versioning, which should help. This library just depends on "0.2.1", which is actually the same as "^0.2.1", which I believe ends up (or at least should) meaning 0.2.1 <= version < 0.3 in this case: http://doc.crates.io/crates-io.html#using-crates.io-based-crates. The versions used by postgres and rust-mysql-simple should be compatible. If cargo's trying to make two versions of openssl-sys, it seems like a bug.

I've been keeping openssl and openssl-sys versions in lockstep, but that might actually be a bad idea long term. Changes to openssl-sys should be almost entirely additive, which should help prevent most of the breakage from competing versions of openssl itself.

[sfackler]

cc @alexcrichton is my understanding of Cargo's versioning logic correct here?

[ArtemGr]

The versions used by postgres and rust-mysql-simple should be compatible.

So openssl = "0.2.2" in blackbeam/rust-mysql-simple@06edff7 will track openssl until 0.3? That's kind of... counter-intuitive, IMHO.

BTW, the guide says "Caret requirements allow SemVer compatible updates to a specified version", so it might follow that without the caret the updates aren't allowed?

[sfackler]

Yep! The idea is that if the library author (me) doesn't screw up, all of the releases in the 0.2.x series are backwards compatible, so it doesn't matter if you pull in a slightly newer version than the one the library's asking for. It's a bit of a trade off between the risk of things breaking due to an accidental loss of back compat vs libraries being completely non-interoperable because they're locked to slightly different versions of something like openssl-sys.

[ArtemGr]

@sfackler But do we need the caret for this? Or is it implied?

[sfackler]

"x.y.x" is equivalent to "^x.y.z". "=x.y.z" actually locks directly to the one version, and "~x.y.z" is a more conservative version of "^x.y.z".

[ArtemGr]

Oh, sorry for the confusion then. So the only issue remining is for hyper to use the crates then. I'll close the postgresql and mysql bugs, thanks!

[alexcrichton]

@sfackler that sounds right to me