Bump defmt from 0.2.1 to 0.3 - #249

Hi, this is a breaking change - can 0.2 and 0.3 be implemented in parallel instead?

Hi, this is a breaking change - can 0.2 and 0.3 be implemented in parallel instead?

I already checked the code in this repo and none of it is affected by the v0.3 changes. You can see them here: https://defmt.ferrous-systems.com/migration-02-03.html

Users of this library that are still using 0.2 would see breakage, hence it is a breaking change.

Users of this library that are still using 0.2 would see breakage, hence it is a breaking change.

I'm not really sure how this could be achieved since dependencies can only be specified once IIUC (so we can't have a defmt-03 feature in addition to the existing defmt-impl feature).

What would you propose?

One can rename the versions of the crate, e.g. defmt v0.2 as defmt02 as described here: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#renaming-dependencies-in-cargotoml
This should work out fine.

I'm testing here: https://github.com/japaric/heapless/tree/dual-defmt
For some reason this does not work, but we use the same trick in cortex-m-rtic for multiple cortex-m dependencies: https://github.com/rtic-rs/cortex-m-rtic/blob/v0.5.x/Cargo.toml#L63

Not sure what's wrong...

I made a cargo issue, lets see what they say rust-lang/cargo#10066

I think it is a defmt bug: knurling-rs/defmt#625

In the end it's a cargo bug: rust-lang/cargo#5969

We could say in the documentation that the defmt-impl flag enables the "latest" defmt release instead of a specific version.
This would allow us to update defmt in patch releases while it's still quite unstable.

Another idea that I lifted in the defmt issue, use a version range:

[dependencies.defmt]
version = ">=0.2,<0.4"
optional = true

Seems to work, but I'm not sure of unintended consequences.

I fixed a PR for the version range: #251