-
-
Notifications
You must be signed in to change notification settings - Fork 85
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
[RFC] how to manage decoder versions? #596
Comments
as a data point, the wire format has broken twice since the defmt version split landed:
|
another data point, we maintain 3 consumers of the
|
That sounds like we might want to only bump the version between crates.io releases, not when we're just working in git (just to make sure we don't end up with 13 decoders or something). Not sure how that interacts with back-compat tests though.
Some cursory testing reveals that this is impossible – Cargo does not allow a package to depend on different non-breaking versions of the same dependency, only on multiple major versions. I think I'd say we go with option 2 then, with the caveat that we'll only bump the protocol version between actual releases, not for git-only changes. |
hmm, bumping the version number per PR would let git users of probe-run get the "pre Flash & Run" 'mismatch version' error message instead of a runtime decoder error. I do agree that we should not release one decoder crate for each PR that breaks the wire format. we could do decoder release less often so that e.g. decoder 0.3.0 supports defmt-version-3 and decoder 0.4.0 supports defmt-version-7 with all the versions in between (4, 5, 6) being git only.
To clarify, I meant "minor version" in the context of a pre-1.0 crate so there can be semver breaking changes between those. [dependencies]
futures-01 = { package = "futures", version = "0.1.0" }
futures-03 = { package = "futures", version = "0.3.0" } |
I don't think we need to block the 0.3.0 on a decision on this RFC. At the latest, we'll need a decision when it's time to make a release that needs to support more than one decoder and that will be needed when we land a backward incompatible wire change after the 0.3.0 release. So, I'm going to de-milestone this issue and instead put the docs PR #615 on the 0.3.0 milestone. |
(this is probably more of probe-run issue but a solution may involve changes in defmt-decoder so posting in this issue tracker)
we version defmt in
defmt-decoder
so now a tool likeprobe-run
can tell the user it doesn't know about a newer defmt-version and that the tool needs to be updated.that's all good but presumably we want newer patch releases of probe-run to also support older defmt-versions so question is how do we approach that
1. one defmt-decoder per defmt-version
one way is to do a new minor release of
defmt-decoder
every time defmt-version increases.then probe-run can depend on multiple minor versions of defmt-decoder.
however, for this to work probe-run needs to extract the defmt-version from the ELF so it can pick the right minor version of defmt-decoder to parse the rest of the table.
presumably, it needs to extract the version from the ELF without using any version of
defmt-decoder
.other tools, like
defmt-print
, would also need to version extraction logic to support multipledefmt-decoder
versions2. multiple defmt-versions per defmt-decoder
the other way I see is handling the versions transparently in
defmt-decoder
itself.That would imply having different paths in the code to handle different versions.
with this approach, we can do newer patch releases of
defmt-decoder
that support multiple defmt-versions.the advantage is that tools can depend on a single minor version of
defmt-decoder
and gain, without extra work, support for newer versions.naively, this sounds like more overall work that the first option but I guess it also depends on how many tools we are maintaining using option 1.
3. one probe-run per defmt-version
the third option that requires the least amount of work is to NOT do this and instead do a new minor release of defmt-decoder AND a new minor release of probe-run when defmt-version is bumped.
thoughts? @jonas-schievink
The text was updated successfully, but these errors were encountered: