Conversation
This is necessary to implement a custom `Decode` for `BoundedVec`. See: paritytech/polkadot#6603 (comment) > You want to ensure that you don't even start try decoding/allocating when the length of the vector is more than the > allowed maximum. > You first decode length of the vector and then early reject if that is too long.
|
@mrcnski you also need to bump the patch version and then release this version! |
|
@bkchr I'll need some help with that. Should the version bump be a separate PR? How do I release it? (I don't think I have access rights, or do I?) |
|
You can bump the patch version in this pr. Then merge it. Then do cargo publish. Then go on github and create some new release. I can create the github release for you if you don't know how to. |
|
Okay! Technically though, shouldn't this be a minor version bump as we are adding to the public API? |
Why not? We don't break anything? I mean we can also bump the minor version 🤷 |
|
@bkchr The major version is > 0 so a minor version bump doesn't denote a breaking change, it just means that functionality was added. |
I know. I read again semver: Let's bump the minor. I general before I meant that you can do whatever you want :D I would not have blocked you on bumping the minor :D |
|
Cool, I was able to |
This is necessary to fix the custom
impl DecodeforBoundedVec. Currently when decoding, it will allocate before doing a length check. See:paritytech/polkadot#6603 (comment)