search

OpenZeppelin / polkadot-runtime-templates

Runtime Templates for Polkadot Parachains
GNU General Public License v3.0
59 stars 17 forks source link

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

Open 4meta5 opened 3 months ago

4meta5 commented 3 months ago

templates

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

ozgunozerk commented 3 months ago

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 commented 3 months ago

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 commented 3 weeks ago

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

ggonzalez94 commented 2 weeks ago

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

4meta5 commented 1 week ago

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:

4meta5 commented 1 week ago

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

ozgunozerk commented 1 week ago

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 commented 1 week ago

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

4meta5 commented 1 week ago

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.