Remove exact version constraint from libc #16955
Conversation
As a system dependency, libc can only be used with a single version in the dependency graph. As such, restricting it to a single fixed version will prevent dependents from specifying a higher version and make deno impossible to use should they require it.
|
CI failure is unrelated to the patch as far as I can tell. |
There was a problem hiding this comment.
LGTM. We pin all versions in the cli to reduce the chance of being bitten by cargo publish patch version breakage, but now that this has moved to the workspace that doesn't make as much sense. We might want to pin this versions in the CLI crate only in the future if it becomes a problem again.
|
I feel like a lockfile should mostly help with that if that's a common issue. That said, there's pretty much no scenario where I would recommend pinning system libs because while in this case the issue was for consumers of deno, it could easily happen the other way around. All it takes is one dependency that pulls libc to define a higher version than what deno defines. I also think that with libc the chances of patch versions breaking stuff are rather low. So that should probably help out too. That said, since I'm personally not using |
cargo publish ignores the lockfile. It's bit us so many times because crates will publish breaking changes in patch releases very often. |
As a system dependency, libc can only be used with a single version in the dependency graph. As such, restricting it to a single fixed version will prevent dependents from specifying a higher version and make deno impossible to use should they require it.
I've run into this issue when building with a dependent that has a version constraint of
0.2.135. I could have just bumped the libc version to the latest available version, but since I didn't see any reason in the git history for why this was explicitly locked down to a single version I assume it was just a mistake.