Release v3.2.0

[Dengjianping]

Signed-off-by: Dengjianping djptux@gmail.com

Description

closes: #553

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
• Wrote unit tests.
• Updated relevant documentation in the code.
• Added one line describing your change in <branch>/CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer.
• If runtime changes, need to update the version numbers properly:
  • authoring_version: The version of the authorship interface. An authoring node will not attempt to author blocks unless this is equal to its native runtime.
  • spec_version: The version of the runtime specification. A full node will not attempt to use its native runtime in substitute for the on-chain Wasm runtime unless all of spec_name, spec_version, and authoring_version are the same between Wasm and native.
  • impl_version: The version of the implementation of the specification. Nodes are free to ignore this; it serves only as an indication that the code is different; as long as the other two versions are the same then while the actual code may be different, it is nonetheless required to do the same thing. Non-consensus-breaking optimizations are about the only changes that could be made which would result in only the impl_version changing.
  • transaction_version: The version of the extrinsics interface. This number must be updated in the following circumstances: extrinsic parameters (number, order, or types) have been changed; extrinsics or pallets have been removed; or the pallet order in the construct_runtime! macro or extrinsic order in a pallet has been changed. You can run the metadata_diff.yml workflow for help. If this number is updated, then the spec_version must also be updated
• Verify benchmarks & weights have been updated for any modified runtime logics
• If importing a new pallet, choose a proper module index for it, and allow it in BaseFilter. Ensure every extrinsic works from front-end. If there's corresponding tool, ensure both work for each other.
• If needed, update our Javascript/Typescript APIs. These APIs are officially used by exchanges or community developers.
• If modifying existing runtime storage items, make sure to implement storage migrations for the runtime and test them with try-runtime. This includes migrations inherited from upstream changes, and you can search the diffs for modifications of #[pallet::storage] items to check for any.

[Dengjianping]

Wait #554 to be merged.

[ghzlatarev]

Are you going to modify the Sudo migration to drain the pallet-version storage ?

[Dengjianping]

Are you going to modify the Sudo migration to drain the pallet-version storage ?

Sure, I'm testing it locally now.

[stechu]

LGTM. need to merge #529 first tho.

[Garandor]

holding off on review until #529 is merged

[Garandor]

Asset-manager needs a try-runtime implementation in pallets/asset-manager/src/lib.rs:567

[ghzlatarev]

@Dengjianping there's one more issue with https://github.com/Manta-Network/Manta/blob/manta/pallets/asset-manager/src/lib.rs#L535 It should be

Junctions::X2(Junction::Parachain(para_id), _) => {
					AllowedDestParaIds::<T>::contains_key(para_id)
				}

Otherwise we won't be able to send to AccountKey20 types for example

[stechu]

@Dengjianping there's one more issue with https://github.com/Manta-Network/Manta/blob/manta/pallets/asset-manager/src/lib.rs#L535 It should be

Junctions::X2(Junction::Parachain(para_id), _) => {
					AllowedDestParaIds::<T>::contains_key(para_id)
				}

Otherwise we won't be able to send to AccountKey20 types for example

Good catch

[Dengjianping]

Asset-manager needs a try-runtime implementation in pallets/asset-manager/src/lib.rs:567

Not sure what you mean.

There's on_runtime_upgrade hook in asset-manager, try-runtime can find it automatically, imo.
This is the log from try-runtime CI:

AssetManager declares internal migrations (which *might* execute). On-chain `StorageVersion(0)` vs current storage version `StorageVersion(0)`  

Perhaps I have to bump pallet-version?

[Garandor]

Asset-manager needs a try-runtime implementation in pallets/asset-manager/src/lib.rs:567

Not sure what you mean.

There's on_runtime_upgrade hook in asset-manager

the actual runtime upgrade must not fail/panic, so if the upgrade fails to apply cleanly, on_runtime_upgrade will just ignore the error.

We want the migration to do two additional things:

• have a pre/postcondition check that can simulate the upgrade and panic (or at least print failure) if the function in on_runtime_upgrade would throw an error. This can be done with pre/post migration steps used with try_runtime, as in pallets/collator-selection/src/migrations.rs:68
• Ensure the migration only executes once, unless you can guarantee that it's invariant on reexecution. Easiest thing to do is check against pallet_version and bump it after the upgrade, or check the specific runtime version

see also

#[cfg(feature = "try-runtime")]
fn pre_upgrade() -> Result<(), &'static str> { Ok(()) }

#[cfg(feature = "try-runtime")]
fn post_upgrade() -> Result<(), &'static str> { Ok(()) }

in https://docs.substrate.io/v3/tools/try-runtime/

[Garandor]

I'll schedule #460 for the 3.2.1 release to clean up the old PalletVersion storage that is becoming unused as we migrate to storageVersion

see https://paritytech.github.io/substrate/master/src/frame_support/migrations.rs.html#36 of https://paritytech.github.io/substrate/master/frame_support/migrations/fn.migrate_from_pallet_version_to_storage_version.html

[Garandor]

LGTM besides my comments

[stechu]

pending #583 's merge.

[Garandor]

LGTM, thanks!