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.)
tcharding
force-pushed
the
push-tqxsqoptvrzu
branch
from
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.
tcharding
force-pushed
the
push-tqxsqoptvrzu
branch
from
c2dafe9 to
52da558
Compare
|
@apoelstra can we get this in and release ref: rust-bitcoin/rust-bitcoin#5742 EDIT: #210 - LFG! |
Only if we semver-trick the existing 1.0 types into it. |
|
@tcharding can you clarify what your intent here is? After this PR I can run
|
|
Am I on drugs; you got the re #203; this branch is master, it has that? |
Meta conversation: Some times we have things that seem like they need more bandwidth than one comment then 24 hours to get a response. I thought this yesterday when writing rust-bitcoin/rust-bitcoin#5839 and here is a perfect example. We can't semver 1.0 types on master and then release master as 1.1 IIUC we have two choices only:
This PR does (2). I would expect the upgrade path to be different for different projects. Those using stable and not caring about RC testing
Those doing RC testing i.e.,
|
We never need to "semver trick" 1.0 types into 1.1. Cargo will always unify the minor versions of 1.x across the dependency tree.
Ah, yes, you're right. Okay, I see what you're trying to do here.
...yes, and it will also mean that nobody can use our crates alongside
These should be fine, we just need to get the version numbers right. |
|
TL;DR lets just release
Yep yep, but
What about we merge this. Gather the whole team together and turn the crank on master (API checklist, docs, etc) for a week (or two ...). Then release the crate with no RC release, dust our hands, and just say, "that's the best we can do and fuck you if you don't like it"? The RC is not going to catch anything because there is basically no change to
I personally have no faith in |
2 participants
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.