Update defmt_decoder

[bugadani]

Closes #2153
Closes #2155

knurling/ferrous really doesn't want us using defmt_decoder, so I'm open to alternatives

[MabezDev]

Thanks!

[Urhengulas]

knurling/ferrous really doesn't want us using defmt_decoder, so I'm open to alternatives

We do! What would make it easier for you?

[bugadani]

We do! What would make it easier for you?

That's great! However, the library is currently marked as follows:

//! This is an implementation detail of [`probe-run`](https://github.com/knurling-rs/probe-run) and
//! not meant to be consumed by other tools at the moment so all the API is unstable.

In my opinion this is not a very friendly guarantee (or, lack thereof), especially when the internals are tied to an archived/deprecated project :)

From my personal POV, defmt has been around unstably for long enough without much change and probably without huge need for change. In my opinion it's time to start moving down the 1.0 route, or at least to offer some better-then-nothing guarantees for incorporating crates into third party host software.

All I'd like to see is probe-rs to not break if a new defmt_decoder is released. This issue also affects espflash, which is similarly a consumer of defmt_decoder (and defmt_parser for some reason I no longer remember). I understand that semver doesn't guarantee any stability for 0.x releases. I also understand that certain other aspects (like MSRV changes!) are not covered by semver at all. However, cargo's version resolution stil considers patch releases compatible, even for 0.x. Most libraries I've interacted with usually consider this compatibility when they introduce breaking changes.

Since we now have the library pinned to =0.3.10 maybe possible breaking changes are no longer an issue, but now we need to spend time evaluating whether we can or can not update to a new patch release with reasonable effort.

Sorry if this got a bit rant-y.

[Urhengulas]

Sorry if this got a bit rant-y.

No worries. I get the point.

From my personal POV, defmt has been around unstably for long enough without much change and probably without huge need for change. In my opinion it's time to start moving down the 1.0 route, or at least to offer some better-then-nothing guarantees for incorporating crates into third party host software.

To be honest it was not a very conscious decision to keep the API unstable. It was more of a case of "it works for us", so we didn't bother stabilizing it.

And a small nit: the defmt API is stable. What is unstable are the "internal" crates defmt-parser, defmt-decoder etc. But I agree that it has been around for long enough to be stabilized.

I will raise the topic internally.