`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.
* Improve handling of unset `StorageVersion`
When a user is forgetting to set the storage version in a pallet and calls
`current_storage_version` to compare it against the `on_chain_storage_version` it will now fail to
compile the code. Before the pallet macro just returned `StorageVersion::default()` for
`current_storage_version` leading to potential issues with migrations. Besides that it also checks
in `post_upgrade` that the pallet storage version was upgraded and thus, no migration was missed.
* Use correct `Cargo.lock`
* Fixes
* Fix test
* Update frame/support/test/tests/pallet.rs
* Ensure we don't set a storage version when the pallet is missing the attribute
* Fix merge conflict
* Update frame/support/procedural/src/pallet/expand/hooks.rs
Co-authored-by: Roman Useinov <roman.useinov@gmail.com>
* Update frame/support/procedural/src/pallet/expand/hooks.rs
Co-authored-by: Roman Useinov <roman.useinov@gmail.com>
* Fix compilation
* Do not run everything with `try-runtime`
* Fix test
* Apply suggestions from code review
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
* Fix `no-metadata-docs`
---------
Co-authored-by: Roman Useinov <roman.useinov@gmail.com>
Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io>
Co-authored-by: parity-processbot <>
* Change copyright year to 2023 from 2022
* Fix incorrect update of copyright year
* Remove years from copy right header
* Fix remaining files
* Fix typo in a header and remove update-copyright.sh
* update api
* update
* remove unused
* remove `one` api
* fix unused
* fmt
* add saturating accrue
* remove `Weight::new()`
* use some macros
* div makes no sense
* Update weight_v2.rs
* missed some
* more patch
* fixes
* more fixes
* more fix
* more fix
* Update frame/support/src/weights/weight_v2.rs
* not needed
* fix weight file
* Move `PalletVersion` away from the crate version
Before this pr, `PalletVersion` was referring to the crate version that
hosted the pallet. This pr introduces a custom `package.metadata.frame`
section in the `Cargo.toml` that can contain a `pallet-version` key
value pair. While the value is expected to be a valid u16. If this
key/value pair isn't given, the version is set to 1.
It also changes the `PalletVersion` declaration. We now only have one
`u16` that represents the version. Not a major/minor/patch version. As
the old `PalletVersion` was starting with the `u16` major, decoding the
old values will work.
* Overhaul the entire implementation
- Drop PalletVersion
- Introduce StorageVersion
- StorageVersion needs to be set in the crate and set for the macros
- Added migration
* Fix migrations
* Review feedback
* Remove unneeded dep
* remove pub consts
* Brings back logging and implements `GetStorageVersion`
* Return weight from migration
* Fmt and remove unused import
* Update frame/support/src/dispatch.rs
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
* Update frame/support/src/traits/metadata.rs
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
Co-authored-by: Guillaume Thiolliere <gui.thiolliere@gmail.com>
Liam Aharon