|
rippled
|
Steps required to add new features to the code:
1) In this file, increment numFeatures and add a uint256 declaration for the feature at the bottom 2) Add a uint256 definition for the feature to the corresponding source file (Feature.cpp). Use registerFeature to create the feature with the feature's name, Supported::no, and VoteBehavior::DefaultNo. This should be the only place the feature's name appears in code as a string. 3) Use the uint256 as the parameter to view.rules.enabled() to control flow into new code that this feature limits. 4) If the feature development is COMPLETE, and the feature is ready to be SUPPORTED, change the registerFeature parameter to Supported::yes. 5) When the feature is ready to be ENABLED, change the registerFeature parameter to VoteBehavior::DefaultYes. In general, any newly supported amendments (Supported::yes) should have a VoteBehavior::DefaultNo for at least one full release cycle. High priority bug fixes can be an exception to this rule of thumb.
When a feature has been enabled for several years, the conditional code may be removed, and the feature "retired". To retire a feature: 1) Remove the uint256 declaration from this file. 2) MOVE the uint256 definition in Feature.cpp to the "retired features" section at the end of the file. 3) CHANGE the name of the variable to start with "retired". 4) CHANGE the parameters of the registerFeature call to Supported::yes and VoteBehavior::DefaultNo. The feature must remain registered and supported indefinitely because it still exists in the ledger, but there is no need to vote for it because there's nothing to vote for. If it is removed completely from the code, any instances running that code will get amendment blocked. Removing the feature from the ledger is beyond the scope of these instructions.
1.8.17