System XLS: Renaming ripple(d) to xrpl(d)

[bthomee]

1 Introduction

In the initial phases of development of the XRPL, the open source codebase was called “rippled” and it remains with that name even today. Today, over 1000 nodes run the application, and code contributions have been submitted by developers located around the world. The XRPL community is larger than ever. We at Ripple are proposing a few changes to the project in light of the decentralized and diversified nature of XRPL.

Some of what we propose here was floated previously (see items 7 and 8), but ultimately was not followed up on. We are now taking this up again, because we deem it still to be the right thing to do.

2 Proposal

We propose to make the following changes.

2.1 Repository

We propose to rename the rippled GitHub repository to xrpld. After renaming, the former URL will forward all requests to the latter URL, so anyone with the old link will still be able to find the codebase.

2.2 Binary

We propose to rename the rippled binary to xrpld, and add a symlink named rippled that points to xrpld, so that node operators do not have to change anything on their end initially. We further propose to remove this symlink six months later to complete the switchover.

2.3 Config

We propose to rename the rippled.cfg configuration file to xrpld.cfg, and to modify the code to accept both files. As above, we further propose to remove the old configuration file six months later to complete the switchover.

2.4 Namespace

We propose to rename the ripple C++ namespace to xrpl. This will require other projects, such as clio to make a one-time update to their codebase as well, which we will help them with.

2.5 Include guards

C++ include guards are used to prevent the contents of a header file from being included multiple times in a single compilation unit. These include guards currently start with RIPPLE_ or RIPPLED_. We propose to rename both prefixes to XRPL_.

An alternative approach is to replace the include guards by #pragma once, however this may not work with the symlinks we rely on inside cmake/RippledCore.cmake to separate headers into modules. We will try this approach first before renaming.

2.6 CMake

We propose to rename the compiler files from RippleXXX.cmake or RippledXXX.cmake to XrplXXX.cmake, and any references to ripple and rippled (with or without capital letters) to xrpl and xrpld, respectively.

2.7 Code and comments

We propose to rename references to ripple and rippled (with or without capital letters) to xrpl and xrpld, respectively. We will leave flags such as tfNoRippleDirect and ltRIPPLE_STATE untouched, as those do not refer to the company but to the concept of rippling.

2.8 Artifacts

The .rpm and .deb packages, and the Docker image will be renamed too. As above, we will maintain the current artifacts for a period of six months, after which they will no longer be updated.

2.9 Copyright notices

The root of the repository contains a LICENSE.md file that lists the original contributors for the year of 2011, and the XRP Ledger developers from 2012 onwards, which is as intended. However, this is sometimes inconsistent with the individual copyright notices scattered throughout the codebase, which refer to XRP Ledger developers in different ways.

Going forward, unless the copyright notices in individual files reference public code used from external projects (e.g. Bitcoin), such notices will be removed and the license file in the root of the repo will consistently apply throughout.

2.10 Ripple epoch

We propose to rename the Ripple epoch, which refers to the timestamp of 01/01/2001 at 0:00 UTC, to XRPL epoch.

These changes should also be made in the various xrpl libraries, where functions such as xrpl.utils.datetime_to_ripple_time will be maintained for six months. During that time period they will forward calls to the renamed function and will print a warning to the log about the deprecation.

2.11 Other

After making the changes proposed above, there will invariably be a few references that we somehow missed, or newly appeared after an open PR gets merged. We will update these on a case-by-case basis.

2.12 Documentation

Once all references have been updated throughout the XRPLF codebases, we will also update the docs, code, samples, and tutorials hosted at xrpl.org.

3 Implementation

To minimize disruption to contributors, operators, and others, we aim to implement the proposed changes as follows.

3.1 Execution

We will first make the changes that are purely cosmetic and do not require any action by the community:

• Include guards
• CMake
• Code and comments
• Copyright notices

We will next make the changes that should also be safe but carry some risk of unexpected behavior:

• Config
• Binary

We will finally make the changes that may require action from some community members and that carry more risk:

• Repository
• Namespace
• Ripple epoch
• Artifacts

Each of the proposed changes listed above will be made separately. To avoid contributors having to rebase their PRs many times, we will perform the changes in the first group quickly. As the third group of changes are the most impactful and may need extensive collaboration with the community, we will roll them out slowly.

3.2 Script

To assist developers in making the same changes to their forks or open PRs, we will add a script to the repository that will apply all changes to their local branch. This script will be updated each time we make a change.

3.3 Support

Contributors, operators, and others may need to take some actions as part of this proposal. For instance, build failures are expected in PRs after we rename the namespace from ripple to xrpl. We will work with each of them to ensure the changes occur as smoothly as possible.