Stabilize VersionedMigration (#1503)

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

substrate/frame/society/Cargo.toml

@@ -34,8 +34,6 @@ sp-io = { path = "../../primitives/io" }
 
 [features]
 default = [ "std" ]
-# Enable `VersionedMigration` for migrations using this feature.
-experimental = [ "frame-support/experimental" ]
 std = [
 	"codec/std",
 	"frame-benchmarking?/std",

substrate/frame/society/src/migrations.rs

@@ -95,7 +95,6 @@ impl<
 
 /// [`VersionUncheckedMigrateToV2`] wrapped in a [`frame_support::migrations::VersionedMigration`],
 /// ensuring the migration is only performed when on-chain version is 0.
-#[cfg(feature = "experimental")]
 pub type VersionCheckedMigrateToV2<T, I, PastPayouts> =
 	frame_support::migrations::VersionedMigration<
 		0,

substrate/frame/support/src/migrations.rs

@@ -24,9 +24,7 @@ use sp_core::Get;
 use sp_io::{hashing::twox_128, storage::clear_prefix, KillStorageResult};
 use sp_std::marker::PhantomData;
 
-/// EXPERIMENTAL: The API of this feature may change.
-///
-/// Make it easier to write versioned runtime upgrades.
+/// Handles storage migration pallet versioning.
 ///
 /// [`VersionedMigration`] allows developers to write migrations without worrying about checking and
 /// setting storage versions. Instead, the developer wraps their migration in this struct which
@@ -69,14 +67,12 @@ use sp_std::marker::PhantomData;
 /// 	// other migrations...
 /// );
 /// ```
-#[cfg(feature = "experimental")]
 pub struct VersionedMigration<const FROM: u16, const TO: u16, Inner, Pallet, Weight> {
 	_marker: PhantomData<(Inner, Pallet, Weight)>,
 }
 
 /// A helper enum to wrap the pre_upgrade bytes like an Option before passing them to post_upgrade.
 /// This enum is used rather than an Option to make the API clearer to the developer.
-#[cfg(feature = "experimental")]
 #[derive(codec::Encode, codec::Decode)]
 pub enum VersionedPostUpgradeData {
 	/// The migration ran, inner vec contains pre_upgrade data.
@@ -91,7 +87,6 @@ pub enum VersionedPostUpgradeData {
 /// version of the pallets storage matches `From`, and after the upgrade set the on-chain storage to
 /// `To`. If the versions do not match, it writes a log notifying the developer that the migration
 /// is a noop.
-#[cfg(feature = "experimental")]
 impl<
 		const FROM: u16,
 		const TO: u16,

substrate/frame/support/test/tests/versioned_migration.rs

@@ -17,7 +17,7 @@
 
 //! Tests for [`VersionedMigration`]
 
-#![cfg(all(feature = "experimental", feature = "try-runtime"))]
+#![cfg(feature = "try-runtime")]
 
 use frame_support::{
 	construct_runtime, derive_impl,