-
Notifications
You must be signed in to change notification settings - Fork 629
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[XCM] Move XCM into its own repo #610
Comments
I agree with this but wondering how this affects the mono effort. |
I think it's fine. Including it under polkadot was only ever meant to be temporary while XCM was evolving fast. As the design becomes more stable and improvements become incremental then I think it'll be really good to introduce proper versioning and publishing. In particular I look forward to iterating fast on XCMv4 in the xcm/xcm-executor/-builder/-pallet while keeping the XCM used in Polkadot stable at v3 until v4 is audited and stabilises. This was a big pain point with the delivery of XCMv3. |
Above I created an overview of all the open PRs that touch the xcm directory that should either be merged before we move to the new repo, or that should be moved to the new repo. I added all the PRs that where opened in 2023. If there are PRs that I missed or where opened before 2023 and should be added, add them to the overview. I would like to ask the authors of the PRs to add to the last column if the PR should be merged before, they will move the PR over to the new repo or if the PR is not relevant anymore. Keep in mind that merging before will block the move to the new repo. |
I think what this means is that XCM has to be stand alone and can no longer depend on Substrate since that will move in with Polkadot (monorepo) and would create a cyclic dependency. |
We should move XCM into its own repo as a first step for decoupling it with Polkadot.
The overview of open PRs touching the xcm directory
remote_message
estimationT::BlockWeights::get().max_block
->Weight::MAX
haul_blob
with Channel + includeNetworkId
to channel idAssetId
andMultiLocation
non-Copy
The text was updated successfully, but these errors were encountered: