-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
version conflicts #22
Comments
Yeah, it would be good to improve this. I think it's mostly up to defmt and Cargo to provide better handling of dependencies that use |
Ok, I see the |
I've opened #35 to make defmt support opt-in, and to allow patch versions of bxcan to update defmt (which normally would be considered a breaking change). This should lift some of the burden from HALs, since they no longer need to update to a new breaking bxcan release every time a new defmt version comes out. Naturally, the drawback is that the defmt version may change, so that means that mostly only applications (which check in their lockfile) would want to use the defmt feature. |
I am building some things that work with multiple device crates and have just started getting
cargo update
errors because one crate has updatebxcan
while another has not:It seems that
bxcan
demands a specific version ofdefmt
and also in theREADME.md
usage suggests demanding a specific version ofbxcan
(nowbxcan = "0.5.0"
but I see it is updated automatically).Any chance you can be more flexible by depending on
defmt = "^..."
or">=..."
and suggest similar flexibility regardingbxcan
in yourREADME
?The text was updated successfully, but these errors were encountered: