7

I noticed that the parity-scale-codec versions 3.0.0, 3.1.0 and 3.1.1 have been yanked: https://crates.io/crates/parity-scale-codec/versions.

The changelog of the crate doesn't contain any information about this though. Is it no longer recommended to use those versions?

2 Answers 2

6

Based on the diffs, upgrading to bitvec 1.0 broke the serialization format of those types that used bit vectors. Version 3.1.2 is the first release that fixed that regression, so to be on the safe side, the broken versions were yanked.

10

To expand on wigy's answer, basically the bitvec type and lsb/msb identifier were reversed. To put this into context, instead of the metadata types returning BitVec<u8, lsb> it returned BitVec<lsb, u8>.

From a middleware perspective, e.g. the Python, Java, JS, Go, ..., etc. APIs this could be quite problematic especially in the cases where they assumed a fixed ordering for the type fields. Since we also don't get the version of scale-info in the metadata to allow for different codepaths, this was an unintended breaking change and could have required upgrades for all developers building cli tools, UIs, etc. on top of Substrate.

The JS API was certainly impacted immediately when the original 3.0 was used in Substrate, although it is now a bit smarter and can handle these fields in any order by looking at the type paths to detect which field goes where.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.