Release 1.0 runtimes

[bkchr]

The repository should now be prepared enough to create the first runtime release from this repo. Parity released all crates alongside releasing the 1.0 release of the node. As the 1.0 release is now already out for some time, I propose that we do the runtimes 1.0 release based on the next Parity Polkadot node release.

So, we first need to wait for this next node release to happen. After the release happened, someone can propose a pull request that updates to these crates on crates.io.

CC @ggwpez @coderobe

[bkchr]

BTW, this time we don't want to copy the commits as before. From this point on this repo will work independently from the Parity repos when it comes to updating the runtimes. The runtimes in this repo are also the canonical ones.

[ggwpez]

So, we first need to wait for this next node release to happen. After the release happened, someone can propose a pull request that updates to these crates on crates.io.

Replacing the dependencies to use crates-io instead of git? okay.

BTW, this time we don't want to copy the commits as before. From this point on this repo will work independently from the Parity repos when it comes to updating the runtimes. The runtimes in this repo are also the canonical ones.

😌 so just copying the changes instead of the full history?

[bkchr]

o just copying the changes instead of the full history?

Yes

Replacing the dependencies to use crates-io instead of git? okay.

I mean I hope we get the latest release this week on crates.io, otherwise we need to use git dependencies.

[acatangiu]

What’s the timeline here? When can we expect a new runtime release?

Seeing how node v1.1.0 is out should we not release runtimes 1.1.0 directly (instead of v1.0)?

[bkchr]

#28 it is being worked on here.

And yes it will be passed on 1.1.0.

[acatangiu]

#28 was merged. Can we do a release now? We need a runtime release for BEEFY on Kusama.
Anything I can help with getting this over the finish line?

[bkchr]

We need to wait for the staking changes runtime upgrade to be approved. After that is approved, we need to merge this fix here to make the repo canonical again. Then we can bring the release over the finish line. I think we can actually do that before the fix is enacted on chain, but we should be certain that it gets enacted on chain.

Maybe we can then do the next release faster...

[acatangiu]

Ok, thanks for the context! 👍

[bkchr]

So, I would like to merge the following pr first: #63

After this pr is merged, we can update this pr #26 and then finally do the release.

[joepetrowski]

Also required:

• Switch Collectives Slash Handler to Use Limited Teleport Assets #46
• increase MAX_ASSETS_FOR_BUY_EXECUTION paritytech/polkadot-sdk#1733 (IMO this is a short term solution but will allow backwards compatibility for some XCM programs already being sent)
• Fix failing integration tests that causes parachains to stall: Needs Do not force collators to update after enabling async backing paritytech/polkadot-sdk#1920 backported to node release(s).

[kianenigma]

• [FRAME] Re-normalization migration for pallet-conviction-voting paritytech/polkadot-sdk#125
• Update Polkadot ideal staking rate #26

[NachoPal]

Reason why Parachains stall after relay chain runtime upgrade: paritytech/polkadot-sdk#1923 (comment)

[kianenigma]

No action item needed for paritytech/polkadot-sdk#125 in this release.

Context: VoteLockingPeriod was mistakenly set to 7 days, and in this release it is going back to 28, the value that it should be. This will not impact the user's voting power. At the moment, the lock can be removed sooner than expected in Polkadot. Once we fix this, the locks will be according to the spec. Implementing polkadot-fellows/RFCs#20 (comment) is a different concern and probably will need consideration, but is outside the scope of this release.

[bkchr]

We should not forget to bump the spec_versions.

[acatangiu]

Let's also get

• Add BEEFY capabilities to the Polkadot runtime #65

released.

We want to go live with the Polkadot<>Ethereum bridge by end of year, meaning BEEFY should be active on Polkadot before December.
And activating it has a long tail of actions:

1. release runtime
2. upgrade runtime
3. coordinate validators to rotate keys (register BEEFY keys)
4. governance to enable BEEFY

If we include it in this release we can do 1-3 in parallel for Kusama and Polkadot. Then do 4 on Polkadot once we're happy with stability on Kusama.

Waiting for next release means doing 1->4 between next release and end of December which won't be possible unless fellowship does another release 2, max 3 weeks from now...

[bkchr]

No this will not be included anymore. This can go into the next release. We want to start with the next release shortly after this was has finally be dine (which is hopefully today).

[bkchr]

To not break every downstream user as we have renamed the xcm crate to staging-xcm to have it released on crates.io, I have created the following two prs:

• xcm: Change TypeInfo::path to not include staging paritytech/polkadot-sdk#1948
• Implement replace_segment attribute paritytech/scale-info#197

With these two prs we will have TypeInfo::path not return staging-xcm as one segment and instead xcm. So, the metadata type name shouldn't change and downstream users should not need to change anything. A proper solution is being discussed here: polkadot-js/api#5741 TLDR: Do not reference the type by name as there might be dragons ;)

We will require that both prs are merged and the appropriate crates being relased. For the staging-xcm crate we will need to backport the changes to 1.1.0 and 1.2.0 and release a patch release of the staging-xcm crate.

[bkchr]

Done