1.2.0 Release

[bkontur]

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

TODO

• PR with bump to polkadot@1.5 Upgrade to latest polkadot-sdk@1.5 release #137 (minimal configurations, just to compile)
• PR with bump to polkadot-sdk@1.6.0 Upgrade to latest polkadot-sdk@1.6 release #159
• PR with bump to polkadot-sdk@1.7.0 Upgrade to latest polkadot-sdk@1.7 release #187
• check/fix migrations when 1.1.0 / 1.1.2 deployed Removed migrations from tag v1.1.2 #195
• regenerate weights
  • regenerate weights for all pallets Update runtime weights for 1.2.0 #223
    • ping Upgrade to latest polkadot-sdk@1.7 release #187 (comment)
  • check bridge transfer fee constants
• bump spec_versions to 1_002_000 - done in Upgrade to latest polkadot-sdk@1.7 release #187
• check and bump transaction versions Check transaction_version for 1.2.0 Release for all runtimes #250
• check Nacho's integration tests
  • check/verify e2e tests: OpenGov -> relay to AssetHub - see comment @muharem
• fix #[api_version(7)] impl primitives::runtime_api::ParachainHost - fn node_features + verify what is missing bump ParachainHost to api version 9 #194
• add benchmark cumulus_pallet_parachain_system to SP runtimes
• address comment here
• integration tests improvement - adapt comment fixed by [tests] move to new xcm-emulator format & add P<>K emulated bridge tests #185

  # TODO: replace with `emulated-integration-tests-common@X.Y.Z` from `polkadot-sdk`
  integration-tests-common = { path = "../common" }
  

• remove unneeded dependencies (cargo machete)
• fix pallet_asset_conversion benchmarks [pallet-asset-conversion] Investigate benchmark swap_exact_tokens_for_tokens and MaxSwapPathLength paritytech/polkadot-sdk#3440
• Adds Snowbridge to Kusama and Polkadot Runtimes Adds Snowbridge to Kusama and Polkadot Runtimes #130

[bkchr]

• check try-runtime- [ ]

This is done by CI. Or what you mean?

[bkontur]

• check try-runtime- [ ]

This is done by CI. Or what you mean?

ok, cool, thank you, removed from desc

[h4x3rotab]

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]

@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]

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

[bkontur]

@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]

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]

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?:

• if we do nothing, the encointer runtime will automatically be part of the next release and the corresponding whitelisting/referendum with spec version 1001000
• if we upgrade dependencies, the spec version should be 1002000

[nanometerzhu]

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:

• runtime v1.0.0 -> polkadot-sdk v1.0.0
• runtime v1.1.0 -> polkadot-sdk v1.3.0
• runtime v1.2.0 -> polkadot-sdk v1.5.0

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

[bkchr]

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]

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]

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]

Can we include #122 in this release?

[bkontur]

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]

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 #145

[bkchr]

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]

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?

[acatangiu]

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 #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 #73

[bkchr]

@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]

We need to do paritytech/polkadot-sdk#1323 to reduce the chance of bad values

[liamaharon]

@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 paritytech/polkadot-sdk#1323 to reduce the chance of bad values

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

[bkchr]

@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]

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

• XCM compatibility. What have we done to ensure this won't break XCM compatibility with existing chain again?
• Breaking changes. Are there expected breaking changes and how we notify them to relevant teams? And did we receive acknowledgements about the communications? Simply have some messages in PR is not counted as notification.
• Testing. How are all the new changes in this release tested? Most of them are covered by unit tests and that could be sufficient but how can we know it is sufficient? Are there any changes may require manual tests? How were the manual tests executed? Are there any changes cannot be tested and we should monitor the production deployment? Are there any changes are tested but we should still monitor the production deployment?

And if the identity will be disabled with #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]

• Add Asset Conversion to Polkadot Asset Hub (awaiting PR from @muharem ).
• If we update to Polkadot SDK v1.7.0 then we can also incorporate the Kusama People Chain.

[bkchr]

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]

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]

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

[xlc]

@bkchr sure I can try to help

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

Breaking Changes

• List all the breaking changes and identify the category (Tx version, Extrinsic usage (e.g. deprecate one in favor of another, XCM, runtime API, storage format, others)
• List all the relevant teams to notify and ensure they have acknowledged the breaking change.

Testing

• List all the changes that need manual test and ensure they are tested using the release runtime. Ensure each change is tested and signed off.

Post deployment

• List all the changes that require post deployment monitor (e.g. runtime migrations). Ensure each change is monitored and signed off after deployment.

Appendix

Relevant teams:

• Parachains Teams: For all breaking changes
  • Someone list all the parachain teams here
• Wallet teams: For tx version and extrinsic usage breaking change
  • Someone list all the wallet teams here
• dApp teams: For extrinsic usage, XCM and storage format breaking change
  • Someone list all the dApp teams here, most likely both the parachain teams and wallet teams
• Indexer and block explorer teams: For storage format and XCM breaking change
  • Someone list all the indexer teams and block explorer teams here
• Validators
• Parachain collators
• RPC providers
• End users

---

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]

• 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.

[joepetrowski]

Would like to have the Kusama People Chain launch:

• Kusama People Chain #217

[bkchr]

• Fixes release notes generation #161

[bkontur]

• Fix pallet_nis benchmark for Kusama runtime #229

[bkontur]

Weights were regenerated here:

• Update runtime weights for 1.2.0 #223

Also created two issues for big differences found:

• Investigate too big change for benchmark set_candidacy_bond for 1.2.0 release #230
• Investigate too big change for benchmark teleport_assets / reserve_transfer_assets for 1.2.0 release #231

cc: @eskimor you wanted to be pinged when new weighs are ready, so they are #223

[brenzi]

If possible, include this PR:

• bump encointer protocol pallets to 6.1 #236

[joepetrowski]

• Add Asset Conversion to Polkadot Asset Hub (awaiting PR from @muharem ).
• If we update to Polkadot SDK v1.7.0 then we can also incorporate the Kusama People Chain.

• Asset Hub: Asset Conversion and Swap Weight Trader #218
• Treasury Spend Detects Relative Locations of Native Asset #233

[s0me0ne-unkn0wn]

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:

• Enable async backing for system parachains: Phase 1 #228

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

• Keep im-online events decodable after pallet removal #235

[alexggh]

• Bump pallet-authorithy-discovery to include Fix kusama validators getting 0 backing rewards the first session tey enter the active set  paritytech/polkadot-sdk#3733

[bkontur]

• People chain nit + added to the runtimes-matrix.json #245

[bkontur]

1.2.0 is almost ready, missing just:

From description:

• check and bump transaction versions
  Check transaction_version for 1.2.0 Release for all runtimes #250
• check Nacho's integration tests
  • check/verify e2e tests: OpenGov -> relay to AssetHub - see comment @muharem

From comments:

• People chain nit + added to the runtimes-matrix.json #245
• Treasury Spend Detects Relative Locations of Native Asset #233
• Add the Kusama Coretime Chain runtime #212
  • coretime-kusama nits  seadanda/runtimes#2
• Snowbridge - Fix benchmarks, add fee multipler and move config to Ethereum module #252

[eskimor]

All of them look pretty ready! Let's get this done today! 🚀

[acatangiu]

#245 needs rank3+ approval because it touched CI file

[eskimor]

#245 needs rank3+ approval because it touched CI file

My approval still does not count. Anybody knows why?

[bkchr]

My approval still does not count. Anybody knows why?

It did, please be patient with the CI :P

[bkchr]

check Nacho's integration tests

* [ ]  check/verify e2e tests: OpenGov -> relay to AssetHub - see [comment](https://github.com/polkadot-fellows/runtimes/pull/187/files#r1507284250) @muharem

@bkontur what is up with this?

[NachoPal]

Tests are green, but I had to comment init_state_migration::InitMigrate because I was getting the below error when trying to run Polkadot's runtime upgrade with Chopsticks. It is probably an issue with smoldot.

runtime::state-trie-migration DEBUG: [19993546] 🤖 running migrations on top of MigrationTask { top: To start, child: To start, dyn_top_items: 0, dyn_child_items: 0, dyn_size: 0, size: 0, top_items: 0, child_items: 0 } until MigrationLimits { size: 409600, item: 4800 }
runtime::state-trie-migration TRACE: [19993546] 🤖 migrated a top key, next_top_key = Some(BoundedVec([], 512))
runtime::state-trie-migration TRACE: [19993546] 🤖 migrated a top key, next_top_key = Some(BoundedVec([5, 149, 38, 117, 134, 181, 119, 68, 146, 120, 132, 245, 25, 235, 129, 1, 78, 123, 144, 18, 9, 107, 65, 196, 235, 58, 175, 148, 127, 110, 164, 41], 512))
runtime::state-trie-migration TRACE: [19993546] 🤖 migrated a top key, next_top_key = Some(BoundedVec([6, 222, 61, 138, 84, 210, 126, 68, 169, 213, 206, 24, 150, 24, 242, 45, 78, 123, 144, 18, 9, 107, 65, 196, 235, 58, 175, 148, 127, 110, 164, 41], 512))
runtime::state-trie-migration TRACE: [19993546] 🤖 migrated a top key, next_top_key = Some(BoundedVec([6, 222, 61, 138, 84, 210, 126, 68, 169, 213, 206, 24, 150, 24, 242, 45, 83, 180, 18, 59, 46, 24, 110, 7, 251, 123, 173, 93, 218, 95, 85, 192], 512))
runtime::state-trie-migration TRACE: [19993546] 🤖 migrated a top key, next_top_key = Some(BoundedVec([6, 222, 61, 138, 84, 210, 126, 68, 169, 213, 206, 24, 150, 24, 242, 45, 180, 180, 157, 149, 50, 13, 144, 33, 153, 76, 133, 15, 37, 184, 227, 133], 512))
panicked at /Users/nacho/Desktop/PARITY/Repos/chopsticks/vendor/smoldot/lib/src/executor/storage_diff.rs:207:13:
assertion failed: in_parent_next_key > key

Stack:

Error
    at imports.wbg.__wbg_new_abda76e883ba8a5f (file:///Users/nacho/Desktop/PARITY/Repos/chopsticks/executor/dist/esm/chopsticks_executor.js:801:19)
    at wasm://wasm/00b1e282:wasm-function[1108]:0x191195
    at wasm://wasm/00b1e282:wasm-function[1334]:0x19979c
    at wasm://wasm/00b1e282:wasm-function[1318]:0x1992e0
    at wasm://wasm/00b1e282:wasm-function[245]:0x10b484
    at wasm://wasm/00b1e282:wasm-function[115]:0xba794
    at wasm://wasm/00b1e282:wasm-function[632]:0x16b359
    at wasm://wasm/00b1e282:wasm-function[1476]:0x19aeb1
    at __wbg_adapter_48 (file:///Users/nacho/Desktop/PARITY/Repos/chopsticks/executor/dist/esm/chopsticks_executor.js:384:10)
    at real (file:///Users/nacho/Desktop/PARITY/Repos/chopsticks/executor/dist/esm/chopsticks_executor.js:366:22)



node:internal/event_target:1096
  process.nextTick(() => { throw err; });
                           ^
Error [RuntimeError]: unreachable
    at wasm://wasm/00b1e282:wasm-function[1108]:0x1912ab
    at wasm://wasm/00b1e282:wasm-function[1334]:0x19979c
    at wasm://wasm/00b1e282:wasm-function[1318]:0x1992e0
    at wasm://wasm/00b1e282:wasm-function[245]:0x10b484
    at wasm://wasm/00b1e282:wasm-function[115]:0xba794
    at wasm://wasm/00b1e282:wasm-function[632]:0x16b359
    at wasm://wasm/00b1e282:wasm-function[1476]:0x19aeb1
    at __wbg_adapter_48 (file:///Users/nacho/Desktop/PARITY/Repos/chopsticks/executor/dist/esm/chopsticks_executor.js:384:10)
    at real (file:///Users/nacho/Desktop/PARITY/Repos/chopsticks/executor/dist/esm/chopsticks_executor.js:366:22)
    at node:internal/process/task_queues:140:7

[bkchr]

It is probably an issue with smoldot.

Yeah looks like one.

[bkontur]

Tests are green, but I had to comment init_state_migration::InitMigrate because I was getting the below error when trying to run Polkadot's runtime upgrade with Chopsticks. It is probably an issue with smoldot.

runtime::state-trie-migration DEBUG: [19993546] 🤖 running migrations on top of MigrationTask { top: To start, child: To start, dyn_top_items: 0, dyn_child_items: 0, dyn_size: 0, size: 0, top_items: 0, child_items: 0 } until MigrationLimits { size: 409600, item: 4800 }
runtime::state-trie-migration TRACE: [19993546] 🤖 migrated a top key, next_top_key = Some(BoundedVec([], 512))
runtime::state-trie-migration TRACE: [19993546] 🤖 migrated a top key, next_top_key = Some(BoundedVec([5, 149, 38, 117, 134, 181, 119, 68, 146, 120, 132, 245, 25, 235, 129, 1, 78, 123, 144, 18, 9, 107, 65, 196, 235, 58, 175, 148, 127, 110, 164, 41], 512))
runtime::state-trie-migration TRACE: [19993546] 🤖 migrated a top key, next_top_key = Some(BoundedVec([6, 222, 61, 138, 84, 210, 126, 68, 169, 213, 206, 24, 150, 24, 242, 45, 78, 123, 144, 18, 9, 107, 65, 196, 235, 58, 175, 148, 127, 110, 164, 41], 512))
runtime::state-trie-migration TRACE: [19993546] 🤖 migrated a top key, next_top_key = Some(BoundedVec([6, 222, 61, 138, 84, 210, 126, 68, 169, 213, 206, 24, 150, 24, 242, 45, 83, 180, 18, 59, 46, 24, 110, 7, 251, 123, 173, 93, 218, 95, 85, 192], 512))
runtime::state-trie-migration TRACE: [19993546] 🤖 migrated a top key, next_top_key = Some(BoundedVec([6, 222, 61, 138, 84, 210, 126, 68, 169, 213, 206, 24, 150, 24, 242, 45, 180, 180, 157, 149, 50, 13, 144, 33, 153, 76, 133, 15, 37, 184, 227, 133], 512))
panicked at /Users/nacho/Desktop/PARITY/Repos/chopsticks/vendor/smoldot/lib/src/executor/storage_diff.rs:207:13:
assertion failed: in_parent_next_key > key

Stack:

Error
    at imports.wbg.__wbg_new_abda76e883ba8a5f (file:///Users/nacho/Desktop/PARITY/Repos/chopsticks/executor/dist/esm/chopsticks_executor.js:801:19)
    at wasm://wasm/00b1e282:wasm-function[1108]:0x191195
    at wasm://wasm/00b1e282:wasm-function[1334]:0x19979c
    at wasm://wasm/00b1e282:wasm-function[1318]:0x1992e0
    at wasm://wasm/00b1e282:wasm-function[245]:0x10b484
    at wasm://wasm/00b1e282:wasm-function[115]:0xba794
    at wasm://wasm/00b1e282:wasm-function[632]:0x16b359
    at wasm://wasm/00b1e282:wasm-function[1476]:0x19aeb1
    at __wbg_adapter_48 (file:///Users/nacho/Desktop/PARITY/Repos/chopsticks/executor/dist/esm/chopsticks_executor.js:384:10)
    at real (file:///Users/nacho/Desktop/PARITY/Repos/chopsticks/executor/dist/esm/chopsticks_executor.js:366:22)



node:internal/event_target:1096
  process.nextTick(() => { throw err; });
                           ^
Error [RuntimeError]: unreachable
    at wasm://wasm/00b1e282:wasm-function[1108]:0x1912ab
    at wasm://wasm/00b1e282:wasm-function[1334]:0x19979c
    at wasm://wasm/00b1e282:wasm-function[1318]:0x1992e0
    at wasm://wasm/00b1e282:wasm-function[245]:0x10b484
    at wasm://wasm/00b1e282:wasm-function[115]:0xba794
    at wasm://wasm/00b1e282:wasm-function[632]:0x16b359
    at wasm://wasm/00b1e282:wasm-function[1476]:0x19aeb1
    at __wbg_adapter_48 (file:///Users/nacho/Desktop/PARITY/Repos/chopsticks/executor/dist/esm/chopsticks_executor.js:384:10)
    at real (file:///Users/nacho/Desktop/PARITY/Repos/chopsticks/executor/dist/esm/chopsticks_executor.js:366:22)
    at node:internal/process/task_queues:140:7

@muharem @NachoPal so, can we consider these two points as done, or is anything missing?

• check Nacho's integration tests
  • check/verify e2e tests: OpenGov -> relay to AssetHub - see comment @muharem

[NachoPal]

we consider these two points as done

Yes, you can check the box

[kianenigma]

• we need to make sure that pallet-staking version 29.0.1 is released and used, which is the current version plus Staking ledger bonding fixes paritytech/polkadot-sdk#3639 and (potentially one other patch). This is basically making sure that the bug we fixed in 1.1.3 runtime release won't re-appear. Being worked on by @gpestana.

[bkontur]

• we need to make sure that pallet-staking version 29.0.1 is released and used, which is the current version plus Staking ledger bonding fixes paritytech/polkadot-sdk#3639 and (potentially one other patch). This is basically making sure that the bug we fixed in 1.1.3 runtime release won't re-appear. Being worked on by @gpestana.

So, it looks like everything is marked as done, and this is the last thing.

One question or point: do we want to regenerate fresh weights once more?

I did it for all runtimes here based on main branch commit f5aeb7e8cc024a17a42ca547645f25f2ae28e4f4 commit and after that I also did fresh weights for people-kusama / coretime-kusama and Snowbridge pallets.

I'm just bringing this to your attention because last time it took somewhere between 12 to 23 hours on Oliver's machine (Kusama/Polkadot are the slowest - several hours, while SPs are fast). Maybe there's no need to regenerate for all runtimes, and we could just regenerate for the concrete pallets affected after commit f5aeb7e8cc024a17a42ca547645f25f2ae28e4f4?

I can see just these candidates:

pallet_state_trie_migration
pallet_asset_conversion
pallet_treasury
pallet_staking

E.g. is this ok? 360581f#diff-e7afb81f3cef77f8a1686085f1adaa992122790270bae77eb2e640ad40b12cf4R1560-R1561

	// Use same weights as substrate ones.
	type WeightInfo = pallet_state_trie_migration::weights::SubstrateWeight<Runtime>;

[ggwpez]

I'm just bringing this to your attention because last time it took somewhere between 12 to 23 hours on Oliver's machine (Kusama/Polkadot are the slowest - several hours, while SPs are fast). Maybe there's no need to regenerate for all runtimes, and we could just regenerate for the concrete pallets affected after commit f5aeb7e8cc024a17a42ca547645f25f2ae28e4f4?

I think we used the same weights for the state-trie-migration as on Kusama? So should be fine.
For the other pallet, yea we could regenerate if its quick, but would not want to hold up the release for it.

[bkontur]

I'm just bringing this to your attention because last time it took somewhere between 12 to 23 hours on Oliver's machine (Kusama/Polkadot are the slowest - several hours, while SPs are fast). Maybe there's no need to regenerate for all runtimes, and we could just regenerate for the concrete pallets affected after commit f5aeb7e8cc024a17a42ca547645f25f2ae28e4f4?

I think we used the same weights for the state-trie-migration as on Kusama? So should be fine. For the other pallet, yea we could regenerate if its quick, but would not want to hold up the release for it.

ok, I just did pallet_asset_conversion and pallet_treasury:

• Fresh weights for pallet_treasury and pallet_asset_conversion for 1.2.0 release #256

[acatangiu]

should we close this now?

[bkontur]

1.2.0 is released: https://github.com/polkadot-fellows/runtimes/releases/tag/v1.2.0, next #186