Skip to content
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

Stabilize VersionedMigration #1503

Merged
merged 5 commits into from
Sep 13, 2023

Conversation

liamaharon
Copy link
Contributor

@liamaharon liamaharon commented Sep 12, 2023

VersionedMigration has become somewhat widely used for handling version bumps in migrations the last few months.

It is currently behind the experimental feature flag, requiring every pallet that writes a new migration with version bumps to set up the experimental flag in their own Cargo.tomls, and also for every runtime using these pallets to explicitly enable the experimental flag for each pallet.

This is becoming quite verbose, and I can only see the number of pallets requiring the experimental flag increasing for no other reason than using what has become a commonly used feature.

Additionally, I'm writing migration docs and would like to avoid stepping through how to use the experimental feature to get VersionedMigration working.

Since the feature has been used in production for some time now without any reported issues, is becoming commonly used and ready to advertise in docs, I feel this is a good time to make it non-experimental.

@liamaharon liamaharon added the T1-FRAME This PR/Issue is related to core FRAME, the framework. label Sep 12, 2023
@liamaharon liamaharon requested review from a team September 12, 2023 05:55
@liamaharon liamaharon requested a review from a team as a code owner September 12, 2023 05:55
Copy link
Contributor

@juangirini juangirini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am happy to see that we are "stabilizing" an experimental

substrate/frame/support/src/migrations.rs Outdated Show resolved Hide resolved
@liamaharon liamaharon changed the title Make VersionedMigration non-experimental Stabilize VersionedMigration Sep 13, 2023
@liamaharon liamaharon enabled auto-merge (squash) September 13, 2023 06:27
@liamaharon liamaharon merged commit 72de70c into master Sep 13, 2023
@liamaharon liamaharon deleted the liam-versioned-migration-remove-experimental branch September 13, 2023 07:34
@Polkadot-Forum
Copy link

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/polkadot-release-analysis-v1-2-0/4451/1

bkchr added a commit to polkadot-fellows/runtimes that referenced this pull request Nov 20, 2023
In the PR we bump versions for all dependacy crates from `polkadot-sdk`
and apply all required changes

Changes:
- `parachains_runtime_api_impl` `v5` -> `v7`,
  - from paritytech/polkadot-sdk#1543;
- `Consideration` setup for preimage pallet instances,
  - from  paritytech/polkadot-sdk#1363;
- `experimental` feature removed for `pallet-society`, `pallet-xcm`,
`runtime-common` crates,
  - from paritytech/polkadot-sdk#1503;
- `pallet_election_provider_multi_phase::Config::SignedDepositBase` set
to `GeometricDepositBase`,
  - from paritytech/polkadot-sdk#1547;
- support `open_outbound_hrmp_channel_for_benchmarks_or_tests` func
rename,
  - from paritytech/polkadot-sdk#1422;
- missing weight functions added for `runtime_parachains_hrmp` and
`pallet_preimage`;

TODO:
- [x] Deleted the Copy&paste para scheduler migration from
#26 in
b666613. This should be applied in the
next runtime upgrade, but i did not properly check yet.

---------

Signed-off-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: Bastian Köcher <git@kchr.de>
Co-authored-by: joe petrowski <25483142+joepetrowski@users.noreply.github.com>
bgallois pushed a commit to duniter/duniter-polkadot-sdk that referenced this pull request Mar 25, 2024
`VersionedMigration` has become somewhat widely used for handling
version bumps in migrations the last few months.

It is currently behind the `experimental` feature flag, requiring every
pallet that writes a new migration with version bumps to set up the
`experimental` flag in their own Cargo.tomls, and also for every runtime
using these pallets to explicitly enable the `experimental` flag for
each pallet.

This is becoming quite verbose, and I can only see the number of pallets
requiring the experimental flag increasing for no other reason than
using what has become a commonly used feature.

Additionally, I'm writing migration docs and would like to avoid
stepping through how to use the `experimental` feature to get
`VersionedMigration` working.

Since the feature has been used in production for some time now without
any reported issues, is becoming commonly used and ready to advertise in
docs, I feel this is a good time to make it non-experimental.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T1-FRAME This PR/Issue is related to core FRAME, the framework.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants