`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.
The FRAME development environment provides modules (called "pallets") and support libraries that you can use, modify,
and extend to build the runtime logic to suit the needs of your blockchain.
Liam Aharon
72de70c72d