bump transaction_version

[coderobe]

there have been storage deletions and parameter changes, this bumps the transaction version accordingly

[coderobe]

i'm unsure if this is necessary
if it turns out to be, i will also pick these commits in a pr against master

[EgorPopelyaev]

@coderobe Mara, I think westend also needs to be bumped, there are two new calls were added

[bkchr]

Adding calls or doing anything storage related doesn't requires a transaction version bump. Only if a call has new parameters or a call is being removed requires the bump of the transaction version.

[bkchr]

[forceCleanHrmp] idx: 3 (args: 1 -> 3)
                                             (u32) -> (u32, u32, u32)
                      [forceProcessHrmpOpen] idx: 4 (args: 0 -> 1)
                                             () -> (u32)
                     [forceProcessHrmpClose] idx: 5 (args: 0 -> 1)
                                             () -> (u32)
                     [hrmpCancelOpenRequest] idx: 6 (args: 1 -> 2)
                                             (PolkadotParachainPrimitivesHrmpChannelId) -> (PolkadotParachainPrimitivesHrmpChannelId, u32)

Okay, I had overseen these ones..

The first two are root calls and the last one is only callable by Parachains.

They require that the transaction version is bumped, but if you are pragmatic it probably creates more hassle than it benefits anyone. There is no root account, so no one can use a hardware wallet to create these transactions.

[joepetrowski]

After speaking with some wallet teams, they prefer to bump transaction_version even if it does not affect calls supported in their wallets. Namely for changes to:

• Pallet order
• Call order
• Function signature (number and types of args)

that would prevent accurate decoding of extrinsics from previous versions.

[coderobe]

bot merge

[paritytech-processbot]

Error: Checks failed for 7086ac2