Open
Conversation
Currently the `hex` macro is placed in between the `pub mod` statements, this is a little surprising. Move the `hex` macro down the file after the public decoding functions. No logic change.
Copy the `error` module rustdocs from the `1.x` branch. The `error` module is the same here on `master` except some unit test code which will be unified next.
Stop using `FromHex` and use the crate level decoding functions in the
unit tests of the `error` module.
With this applied (and hex 1.x branch checked out locally) the
following is achieved:
```
diff src/error.rs ~/tmp/hex-1.0/hex-conservative/src/error.rs
69a70
> pub(crate) use write_err;
413,415c414
< use crate::decode_to_array;
< #[cfg(feature = "alloc")]
< use crate::decode_to_vec;
---
> use crate::{decode_to_array, decode_to_vec};
```
Done in preparation for moving the test out of the `parse` module so we can delete the module.
In preparation for deleting the `parse` module (and clobbering the `FromHex` trait) move the unit test to `error` so its obvious we don't loose any test coverage.
We want to delete the `FromHex` trait which this old macro uses. Just delete it and call it a day. (Note we provide a `hex` macro already that works in const contexts.)
c3ecf54 to
c2dafe9
Compare
We would like to release this branch as `v1.1`. Currently the `serde` deserialize logic uses `FromHex` which we would also like to delete. Instead of trying to work out 1.0-able `serde` stuff lets just delete the module. We can put it back in later if anyone screams at us.
We can use the crate level decoding functions.
Remove the `FromHex` usage in crate level docs.
As everywhere else replace `FromHex` with crate level decoding function.
The only thing being deleted is the `FromHex` trait. From 1.0 onwards we provide crate level decoding functions instead of this trait.
Add a script to check for API changes. On the `1.x` branch run the script then copy the output files here. The ideas is that we can then run the script again and check we didn't inadvertently introduce any breaking changes so we can release `master` as `v1.1`.
BOOM! Only green lines in the diff. We can have confidence now that this branch is API compatible with the `1.x` branch.
c2dafe9 to
52da558
Compare
This was referenced Mar 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The alarming diffstat is caused by the API text files.
Full disclosure; I had PTSD from 1.0-ing this crate, I should have prepared the
v1.1release months and months ago - my bad. Turns out after I made the creative leap to copy the code back from 1.0 instead of the other way around this wasn't that hard.The bit I'm patting my self on the back about is the last two patches: (1) create API text files on the
1.xbranch and commit them on master (as well as a script). (2) run the script again, resulting in only green lines - WIN.The controversial parts of this PR are:
serdemodule - boo hoo.FromHextrait.Before release we will want to go over the whole crate with a fine tooth comb. I propose doing
v0.4.0as an RC release forv1.1.