fix: loosen version constraints #62
Conversation
| regex = "1.7" | ||
| once_cell = "1.16" | ||
| jsonwebtoken = "8.1" | ||
| regex = "1" |
There was a problem hiding this comment.
So what happens if relay_rpc is using features added in 1.7 release, while the consumer code forces e.g. 1.0 version?
There was a problem hiding this comment.
If we needed features/fixes from the 1.7 release, then we would set the minimum to 1.7 not 1 as I did
|
Agreed with Nodar and that PSA. I don't think we should make this change, because of how cargo actually resolves dependency versions. |
chris13524
force-pushed
the
44-tokio-version
branch
from
be0c02d
to
d3ad57a
Compare
chris13524
force-pushed
the
44-tokio-version
branch
from
d3ad57a
to
e856e0a
Compare
|
The PSA linked actually doesn't discourage loosening version constraints like I did, but requests that when doing so that I added this to CI, and looks like indeed these are not appropriate version constraints. Furthermore, I tested minimal-versions against the As discussed in the thread (and the stabilization issue for the flag), fixing this requires all downstream crates getting their dependencies right. Hopefully one day we'll get there and we'll be able to install this CI and loosen our own constraints. But closing this until then. I suppose it's slightly better that, for now, when installing a new package that you use the current version, rather than just the major version. So then you are at least not lying about what version you support. But this could still get outdated as cargo will still install the latest version of the package, which is the one you test against. |
Description
Removes specific version req's. We should be as permissive as possible, letting the downstream app customize the versions. If this library requires a specific minor version or patch, then we can use
^,~or*as appropriateResolves #44
How Has This Been Tested?
Not tested
Due Diligence