search

polkadot-fellows / runtimes

The various runtimes which make up the core subsystems of networks for which the Fellowship is represented.
GNU General Public License v3.0
134 stars 85 forks source link

1.2.0 Release #140

Closed bkontur closed 5 months ago

bkontur commented 8 months ago

Please everyone leave a comment with a link to a pr or issue, so we have it tracked.

TODO

bkchr commented 8 months ago
  • check try-runtime- [ ]

This is done by CI. Or what you mean?

bkontur commented 8 months ago
  • check try-runtime- [ ]

This is done by CI. Or what you mean?

ok, cool, thank you, removed from desc

h4x3rotab commented 8 months ago

Was it intended to keep Polkadot runtime version and the Polkadot SDK version polkadot-vX.Y.Z?

Also, when do we expect 1.2.0 to rollout?

bkontur commented 8 months ago

@brenzi I am not touching encointer now, because iiuc, you need to release new versions of your crates with bumping them to polkadot-sdk@1.5 first, right? So , we can align encointer afterwards. If you need any help, just tell me.

# encointer deps
encointer-balances-tx-payment = { default-features = false, version = "3.0.2" }
encointer-balances-tx-payment-rpc-runtime-api = { default-features = false, version = "3.0.2" }
encointer-primitives = { default-features = false, version = "3.0.2" }
pallet-encointer-balances = { default-features = false, version = "3.0.2" }
pallet-encointer-bazaar = { default-features = false, version = "3.0.2" }
pallet-encointer-bazaar-rpc-runtime-api = { default-features = false, version = "3.0.2" }
pallet-encointer-ceremonies = { default-features = false, version = "3.0.2" }
pallet-encointer-ceremonies-rpc-runtime-api = { default-features = false, version = "3.0.2" }
pallet-encointer-communities = { default-features = false, version = "3.0.2" }
pallet-encointer-communities-rpc-runtime-api = { default-features = false, version = "3.0.2" }
pallet-encointer-faucet = { default-features = false, version = "3.0.2" }
pallet-encointer-reputation-commitments = { default-features = false, version = "3.0.2" }
pallet-encointer-scheduler = { default-features = false, version = "3.0.2" }
brenzi commented 8 months ago

@bkontur let me check. We'd like to be part of the next release and will do the necessary

bkontur commented 8 months ago

@bkontur let me check. We'd like to be part of the next release and will do the necessary

I guess, it is not a problem if you dont bump, encointer will just use old dependencies, it is more about to be up-to-date with latest stuff and be aligned with other SP runtimes

bkchr commented 8 months ago

Was it intended to keep Polkadot runtime version and the Polkadot SDK version polkadot-vX.Y.Z?

I don't get the question?

Also, when do we expect 1.2.0 to rollout?

Probably earliest around end of february.

brenzi commented 8 months ago

it is more about to be up-to-date with latest stuff and be aligned with other SP runtimes

ok. do I get this right?:

nanometerzhu commented 8 months ago

I don't get the question?

I think @h4x3rotab 's question is, even both polkadot-sdk and runtimes have same version format X.Y.Z, but looks like the numbers are different:

Is this unmatched a intended behavior? Is it possible to use same version number so the downstream teams can easier to track?

bkchr commented 8 months ago

Is this unmatched a intended behavior?

Yes, fellowship is not following the release schedule etc of the polkadot-sdk repo. Most of the time the fellowship releases also include multiple polkadot-sdk releases.

Is it possible to use same version number so the downstream teams can easier to track?

If required, we could probably track this in the CHANGELOG file.

eskimor commented 8 months ago

What is the timeline? Can we get coretime in, if everything is ready this week? We need two more PRs which are waiting for audit, so we would need to bump the polkadot-sdk release as well.

bkchr commented 8 months ago

We don't need audits for Kusama.

But I also think, that we can wait for the next polkadot-sdk release in two weeks.

liamaharon commented 8 months ago

Can we include https://github.com/polkadot-fellows/runtimes/pull/122 in this release?

bkontur commented 8 months ago

Can we include #122 in this release?

@liamaharon could this locks migration be related to the error bellow:

for Kusama: https://github.com/polkadot-fellows/runtimes/actions/runs/7553599023/job/20564716882?pr=137

[2024-01-17T09:42:37Z ERROR runtime::executive] - 0. error: Failed to decode storage item `Balances::Locks`
[2024-01-17T09:42:37Z ERROR runtime::executive] - 1. error: Failed to decode storage item `Session::NextKeys`

unrelated to locks for Polkadot: https://github.com/polkadot-fellows/runtimes/actions/runs/7553599023/job/20564716569?pr=137

[2024-01-17T09:46:25Z ERROR runtime::executive] - 0. error: Failed to decode storage item `Proxy::Proxies`
liamaharon commented 8 months ago

Yep, this should fix that unable to decode locks issue.

Not sure why Session::NextKeys is still broken on Kusama... I recall it is supposed to fix after a runtime upgrade, hopefully it self-resolves (@bkchr was that right?)

Proxy::Proxies failing on Polkadot is a new one :') Created an issue, hopefully can fix this week https://github.com/polkadot-fellows/runtimes/issues/145

bkchr commented 8 months ago

I recall it is supposed to fix after a runtime upgrade, hopefully it self-resolves (@bkchr was that right?)

Which runtime upgrade? I think there are maybe still some broken keys in it. I don't remember us fixing this yet.

liamaharon commented 8 months ago

Fix for proxies @bkontur https://github.com/polkadot-fellows/runtimes/pull/150

@bkchr do you know what might be the issue with the session keys or should I take a look? polkadot has a UpgradeSessionKeys migration, maybe Kusama needs one too?

acatangiu commented 8 months ago

Fix for proxies @bkontur #150

@bkchr do you know what might be the issue with the session keys or should I take a look? polkadot has a UpgradeSessionKeys migration, maybe Kusama needs one too?

Current UpgradeSessionKeys in Polkadot was added by https://github.com/polkadot-fellows/runtimes/pull/65 for adding BEEFY session keys - and will be removed once latest release containing it has been upgraded-into on-chain.

Kusama already went through that - UpgradeSessionKeys removed from Kusama in https://github.com/polkadot-fellows/runtimes/pull/73

bkchr commented 8 months ago

@bkchr do you know what might be the issue with the session keys or should I take a look? polkadot has a UpgradeSessionKeys migration, maybe Kusama needs one too?

I just think that this is the problem here. Aka the key is broken there since quite some time and we just always skip it now when doing migrations. Just check how many are broken and then go ahead to remove these from the state. This can probably be done using a kill_storage extrinsic, so we don't need to wait for a runtime upgrade.

xlc commented 8 months ago

We need to do https://github.com/paritytech/polkadot-sdk/issues/1323 to reduce the chance of bad values

liamaharon commented 8 months ago

@bkchr do you know what might be the issue with the session keys or should I take a look? polkadot has a UpgradeSessionKeys migration, maybe Kusama needs one too?

I just think that this is the problem here. Aka the key is broken there since quite some time and we just always skip it now when doing migrations. Just check how many are broken and then go ahead to remove these from the state. This can probably be done using a kill_storage extrinsic, so we don't need to wait for a runtime upgrade.

k, checking the keys 🔎

We need to do https://github.com/paritytech/polkadot-sdk/issues/1323 to reduce the chance of bad values

@xlc this would only catch issues in tests, right? Not directly prevent on-chain issues?

bkchr commented 8 months ago

@xlc this would only catch issues in tests, right? Not directly prevent on-chain issues?

The idea would be that we compile with debug-asserts enabled for when we build the binaries for try-runtime.

xlc commented 7 months ago

I am going to block new runtime releases until the following questions are answered:

And if the identity will be disabled with https://github.com/polkadot-fellows/runtimes/pull/172

Is there a written down identity migration plan? How long will the migration to take? Are UI devs aware of this? Any announcement post?

joepetrowski commented 7 months ago
bkchr commented 7 months ago

I am going to block new runtime releases until the following questions are answered:

You can not just come and block stuff. If you want things to be solved, please help fixing them. You could for example start with a list of relevant teams so that they can be informed of a new release.

joepetrowski commented 7 months ago

Is there a written down identity migration plan? How long will the migration to take? Are UI devs aware of this? Any announcement post?

I posted in the Polkadot Ecosystem matrix chat, will write a Forum post with more info. But it's been done already on Rococo and Westend so it's very easy to see "the plan".

I commented on #172, we should not block Identity in the Relay Chains yet. I will do this in the same PR that adds the People Chain runtime.

joepetrowski commented 7 months ago

Here you go @xlc https://forum.polkadot.network/t/people-chain-launch-and-identity-migration-plan/5930

xlc commented 7 months ago

@bkchr sure I can try to help

I suggest we start making a standard release checklist from the questions I have

Breaking Changes

Testing

Post deployment

Appendix

Relevant teams:

Maybe someone at Parity DevRel team can help with the actual communication and check things off if we have determined there are breaking changes in this release.

And someone should go through the change log and determine if any of them may need manual test / extra test review and then we can do the work.

bkchr commented 7 months ago
  • List all the relevant teams to notify and ensure they have acknowledged the breaking change.

How should this work? We can not always wait for everybody to respond. This will drag everything completely down. I would also like to have more a pull approach from their side. Aka they pull the information instead that we need to push the information to them. I don't know why people always favor the push approach, because it is totally inefficient.

h4x3rotab commented 7 months ago

A pull approach is fine to me. It means we should have a central place to public the breaking change analysis, and wait for maybe at least 7 days for the relevant parties to comment. Only proceed if there's not significant problems.

bkchr commented 7 months ago

I asked that we finally use the prdoc system in polkadot-sdk to generate the changelogs. There are currently 4 or 5 audiences and the changes are explained for the relevant audiences. I would propose that everyone starts to monitor these to interrupt stuff early if needed.

xlc commented 7 months ago

How about mailing list? or something similar like matrix announcement channel. So that people can subscribe to topics relevant to them and receive notifications on updates instead of need to remember to check it every once a while.

It can also be triggered by CI.

bkchr commented 7 months ago

Everything that doesn't require any human interaction for forwarding information is a good solution :D I mean you can get also something similar by subscribing to the polkadot-sdk/fellwowship-runtimes repo releases. If someone wants to write some page or whatever to do these announcements, let's do it!

muharem commented 7 months ago

small fixes:

bkontur commented 7 months ago
bkontur commented 7 months ago
nanometerzhu commented 7 months ago

Hi all, do we have any estimate timeline of this release?

bkontur commented 6 months ago

Hi all, do we have any estimate timeline of this release?

HI @nanometerzhu,

I cannot state the exact date, but I can say what needs to happen first:

  1. this PR needs to be reviewed/merged first, it is ready, just missing fellows reviews (so please review)
  2. after that, we want to merged this PR which unblocks the next point
  3. after that, this PR needs to be reviewed and merged (it is ready, just integration tests from 2. are missing + fellows reviews)
  4. review/merge two small PR and PR + encointer PR (missing fellows reviews)

So I would say: the more reviews we get, the sooner the release can happen :)

bkchr commented 6 months ago
bkontur commented 6 months ago

Fellows, please review the "last" missing piece for this release, a bump to polkadot-sdk@1.7.0: https://github.com/polkadot-fellows/runtimes/pull/187

xlc commented 6 months ago

1.7.0 introduces XCM v4. there is non zero change it will introduce some XCM bugs and yet we still don’t have enough XCM e2e tests.

acatangiu commented 6 months ago

also needed with priority in this release.

eskimor commented 6 months ago

Also:

joepetrowski commented 6 months ago

Would like to have the Kusama People Chain launch:

bkchr commented 6 months ago
bkontur commented 6 months ago
bkontur commented 6 months ago

Weights were regenerated here:

Also created two issues for big differences found:

cc: @eskimor you wanted to be pinged when new weighs are ready, so they are https://github.com/polkadot-fellows/runtimes/pull/223

brenzi commented 6 months ago

If possible, include this PR:

joepetrowski commented 6 months ago
  • [x] Add Asset Conversion to Polkadot Asset Hub (awaiting PR from @muharem ).
  • [x] If we update to Polkadot SDK v1.7.0 then we can also incorporate the Kusama People Chain.
s0me0ne-unkn0wn commented 6 months ago

This one is totally ready and is only waiting for re-review of a single-line Changelog merge, and it would be really great to have it in the current release:

An important one that must be merged before this release (otherwise, #178 must be reverted):