🎁 [Feature Request]: upgrade polkadot-sdk to v1.13.0

[4meta5]

templates

• Generic Runtime Template
• Evm Template

What is the feature you would like to see?

1. choose polkadot-sdk version to upgrade before/until higher priority issues are done. v1.12.0 was released 5 days ago as of writing this
2. upgrade all forks required for external dependencies
3. document and iteratively automate all processes

(1) requires beforehand agreement as a group to choose the stable version. The work required for (2) will determine timing and prioritization of (1).

It may not be ideal to be the first to upgrade all the dependencies i.e. frontier as well as any additional external dep forks required to finish #189 i.e. ORML, Acala, Moonbeam, HydraDX

Contribution Guidelines

• I agree to follow this project's Contribution Guidelines

[ozgunozerk]

We have a specific issue for the 3rd point made for this issue. Better to dump all info we gathered on update process there #93

[4meta5]

We have a specific issue for the 3rd point made for this issue. Better to dump all info we gathered on update process there #93

Cool, my hope is that whoever takes this issue would do work on #93 as part of the process even if they don't necessarily finish #93

[4meta5]

Assigned myself and set the upgrade version as discussed in our meeting today.

[ggonzalez94]

@4meta5 moving this to Milestone 3 since you are already working on it

[4meta5]

Reassigned myself because I upgraded the forks for Moonbeam and ORML.

@ozgunozerk the forked crates that we use (pallet-asset-manager, xcm-primitives) are compiling with the updated dependencies:

• https://github.com/OpenZeppelin/moonbeam/tree/polkadot-v1.13.0
• https://github.com/OpenZeppelin/open-runtime-module-library/tree/polkadot-v1.13.0 (only used by Moonbeam fork, not used directly as far as I recall)

[4meta5]

replaced by #294 @ozgunozerk @ggonzalez94 why did this task require opening a new issue vs updating this issue's title

[ozgunozerk]

the other issue is not a replacement. No need to close this one. The PR addressing the update will close both of them.
We previously planned to upgrade to v1.13.0 and every single one of us contributed to this task.

After that, Nikita suggested we upgrade to even newer version, and I opened a new issue for that, which doesn't neglect this one.

Edit: the reason I opened a new issue instead of updating this one is: that we mentioned this also in the meeting, updating dependencies is not an easy task, and with this one, we updated 5 big versions.

The initial plan was to upgrade to v1.13.0, then after I'm done with the upgrade, with Nikita's suggestion, we decided to upgrade to stable2407-1, basically doubling the workload. Chunking a huge task into 2 smaller issues isn't something new for this repo.
There are currently 2 separate branches (one for v1.13.0 and one for stable2407-1), if you want to review them in a more granular fashion, I can submit 2 PRs instead of a single one

[ozgunozerk]

Assigned also @KitHat since he contributed to evm-node part and fuzzer

[4meta5]

The PR addressing the update will close both of them.

This is/was the issue for whatever version we update to...I still do not see any response to my suggestion to just update the title for this issue.

Regardless the other issue's upgrade builds off of the work done for this upgrade so contributions should carry over.