ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-22 12:45:50 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
080b7562b8567a85979680274749ebc3a6cbb11c
xrpl-dev-portal/content/concepts/consensus-network/amendments/contribute-code-flow.md
Oliver Eggert 080b7562b8 Add flowchart
2023-05-11 15:57:33 -07:00

3.6 KiB
Raw Blame History

html, parent, blurb, labels
html parent blurb labels
contribute-code-flow.html amendments.html
Blockchain

Contribute Code to the XRP Ledger

The software that powers the XRP Ledger is open-source, so anyone can download, modify, extend, or explore it. If you want to contribute code, it's important to work with the community in defining the specifications of your changes and testing the code before adding it to rippled.

XRP Ledger Standards

Changes to rippled are tracked by an XRP Ledger Standard (XLS), a document that identifies and details the specifications of a change. Before committing to development, you must start a discussion in the XRPL-Standards repo. This provides the community a chance to discuss and provide feedback about your change.

Note: Bug fixes don't require an XLS, but may require an amendment.

Creating an XLS has its own process, but can be summarized as:

  1. Starting a discussion and gathering feedback.
  2. Creating an XLS draft in the standards repo.
  3. Publishing the XLS draft as a Candidate Specification.

For details, see the XLS contributing guide.

Amendment Implementation

After you've created an XLSd, you now need to determine if your change requires an amendment. Changes that affect transaction processing require amendments, specifically changes that:

  • Modify ledger rules, resulting in different outcomes.
  • Add or remove transactions.
  • Affect consensus.

Note: If your change doesn't need an amendment, you can go straight to coding and deployment.

Implementing code as an amendment requires you to add the amendment to these files:

  • Feature.cpp:

    Supported parameter should be set to no until development is complete.

    DefaultVote parameter should be set to yes for bug fixes; everything else defaults to no.

  • Feature.h: Increment the numFeatures counter and declare an extern uint256 const variable.

Coding and Deployment

The general development path breaks down as follows:

  1. Create a fork or branch in the rippled repository to develop your code.

    Tip: If you're not sure where to start, Dev Null Productions provides a detailed and thorough rippled Source Code Guide.

  2. Run unit and integration tests. Running a server in stand-alone mode is useful for testing your changes in an isolated environment, but you may want to stand up a private network for extensive changes.

  3. Create a pull request on XRPLF:develop.

    Note for Amendments: Update the Supported paramter to yes in Feature.cpp.

  4. After the pull request is approved by XRP Ledger maintainers, your code is merged into develop and additional testing can be done on Devnet.

    Note for Amendments:

    • The DefaultVote parameter is now locked.
    • If problems are found with the amendment, you must restart the process of making fixes and submitting a new PR. You can change the default vote in the new PR.

  5. On a quarterly basis, a release candidate is built from approved PRs on develop. The package is deployed to Testnet and a few nodes on Mainnet. If no issues are found with the release candidate, the code is merged into master and nodes on Mainnet can upgrade to this build.

  6. New amendments go through the consensus process and validators vote on enabling them or not.

Code Flowchart

![Code Flowchart](img/Contribute Code Flowchart.png)

See Also