io: Update defmt to 1.0, rename feature from "defmt_03" to "defmt" #673
Conversation
…fmt" Being explicit is necessary at this point as long as crates in the workspace have defmt as a dependency but not as a feature.
| # This feature is deprecated; it is left in place while dependencies such as | ||
| # the worspace's embedded-io-async work with either 0.6 and 0.7, but will be | ||
| # removed going to a 1.0 version. | ||
| defmt_03100 = { package = "defmt", version = "0.3.100", optional = true } |
There was a problem hiding this comment.
this dependency shouldn't be needed: if another crate depends on embedded-io and itself uses defmt 0.3 then cargo will automatically pick defmt 0.3.100 for the other and thus defmt 1.0
also: you're not actually using the dependency anywhere in the code anyway, so what's it supposed to do?
There was a problem hiding this comment.
Still having the embedded-io 0.3 feature serves two purposes:
- Right now, embedded-io-async is in the same workspace, has its own defmt-03 feature and depends on the not-yet-version-bumped embedded-io created in this PR. To not have to update -async just yet, this provides a way to keep the build process happy. (This is my primary motivation here).
- For any revdeps that want to use this with defmt 0.3, they might themselves only depend on (say) 0.3.5, and if anything else keeps back defmt from updating to 0.3.100, their dependency might not advance far enough on its own to make the semver trick work.
But I'm not particularly happy about having this workaround still in place; the only other fix that comes to mind to keep CI happy is to do something to embedded-io-async -- either disentangle it from the workspace's version (remove the path= until we're approaching the 0.7/1.0 release) or start co-evolving it. Any preference?
There was a problem hiding this comment.
my comment was about the dependency, not the feature.
as for the feature: i'd probably just update both crates in the repo at the same time in the same way (renaming defmt-03 to defmt).
various other crates bumped from 0.3 to 1.0 as there should be nothing keeping cargo from updating defmt to 0.3.100 since it upheld semver guarantees.
We could do the defmt-1.0 update a bit more compatibly by just going to 0.3.100 (and possibly keeping the defmt_03 feature as a deprecated feature name), but given the discussion in #566 (comment), it may make sense to spool this for a single breaking >>0.6 bump, and use that to get rid of anything that'd be viewed as legacy in a 1.0 version.
One alternative to the hard cut would be to to keep a defmt_03 feature that merely pulls in 0.3.100, as a deprecated feature. If >>0.6 becomes a 0.7 that does the semver trick to 1.0, that feature could be removed as part of the 1.0 transition.An extra deprecated defmt-03 feature is left in place mainly for embedded-io-async, which optionally pulls it in through the path-or-version dependency.