Conversation
|
For my own benefit: I realised just now that the recent releases prior to 3.7.0 all came off the 3.6.x branch, which had the above PRs reverted also. I totally missed this branch when doing the latest release, assuming everything was released off master! I think it would be good to get master back to a sane point. Maybe we should not try to merge this PR at all (which we would do just to get 3.7.1 out, and then want to undo anyways for 4) and instead just release 4.0.0 directly now that we've yanked 3.7.0 and deal with the fallout of this major bump. Does that sound fair? |
@jsdw what you're saying makes sense, but personally I would need a 3.7.1 release soon-ish in order to access the functionality introduced in #616 and I think we would have to wait quite a while for a 4.0 release So could we have a v3.7.x branch for now that would include this PR, and then release 3.7.1 from it ? I can do it if you want. Just please let me know how you prefer |
|
Let's merge this pr and add it to the |
Sounds good to me. We just need to fix the failing test (Rust CI/CD / tests (pull_request)) .@jsdw I can do it if you want. However you prefer. |
| ty.span() => .saturating_add( | ||
| <<#ty as #crate_path::HasCompact>::Type as #crate_path::MaxEncodedLen>::max_encoded_len() | ||
| ) | ||
| ty.span() => .saturating_add(<#crate_path::Compact::<#ty> as #crate_path::MaxEncodedLen>::max_encoded_len()) |
There was a problem hiding this comment.
The code before was actually: ty.span() => .saturating_add(<#ty>::max_encoded_len())
This makes some issue with #691
4 participants
Quick attempt to revert these PRs mentioned in #662 (comment)