Liam Aharon
12ce4f7d04
Closes https://github.com/paritytech/polkadot-sdk-docs/issues/55 - Changes 'current storage version' terminology to less ambiguous 'in-code storage version' (suggestion by @ggwpez) - Adds a new example pallet `pallet-example-single-block-migrations` - Adds a new reference doc to replace https://docs.substrate.io/maintain/runtime-upgrades/ (temporarily living in the pallet while we wait for developer hub PR to merge) - Adds documentation for the `storage_alias` macro - Improves `trait Hooks` docs - Improves `trait GetStorageVersion` docs - Update the suggested patterns for using `VersionedMigration`, so that version unchecked migrations are never exported - Prevents accidental usage of version unchecked migrations in runtimes https://github.com/paritytech/substrate/pull/14421#discussion_r1255467895 - Unversioned migration code is kept inside `mod version_unchecked`, versioned code is kept in `pub mod versioned` - It is necessary to use modules to limit visibility because the inner migration must be `pub`. See https://github.com/rust-lang/rust/issues/30905 and https://internals.rust-lang.org/t/lang-team-minutes-private-in-public-rules/4504/40 for more. ### todo - [x] move to reference docs to proper place within sdk-docs (now that https://github.com/paritytech/polkadot-sdk/pull/2102 is merged) - [x] prdoc --------- Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com> Co-authored-by: Juan <juangirini@gmail.com> Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> Co-authored-by: command-bot <> Co-authored-by: gupnik <nikhilgupta.iitk@gmail.com>
Collective system: Members of a set of account IDs can make their collective feelings known through dispatched calls from one of two specialized origins.
The membership can be provided in one of two ways: either directly, using the Root-dispatchable
function set_members, or indirectly, through implementing the ChangeMembers.
The pallet assumes that the amount of members stays at or below MaxMembers for its weight
calculations, but enforces this neither in set_members nor in change_members_sorted.
A "prime" member may be set to help determine the default vote behavior based on chain
config. If PrimeDefaultVote is used, the prime vote acts as the default vote in case of any
abstentions after the voting period. If MoreThanMajorityThenPrimeDefaultVote is used, then
abstentations will first follow the majority of the collective voting, and then the prime
member.
Voting happens through motions comprising a proposal (i.e. a dispatchable) plus a
number of approvals required for it to pass and be called. Motions are open for members to
vote on for a minimum period given by MotionDuration. As soon as the required number of
approvals is given, the motion is closed and executed. If the number of approvals is not reached
during the voting period, then close may be called by any account in order to force the end
the motion explicitly. If a prime member is defined, then their vote is used instead of any
abstentions and the proposal is executed if there are enough approvals counting the new votes.
If there are not, or if no prime member is set, then the motion is dropped without being executed.
License: Apache-2.0