rippled Release Checklist

This page is a work in progress and you should feel free to update it!

rippled follows a git-flow branching model: https://datasift.github.io/gitflow/IntroducingGitFlow.html

A beta release reflects a synchronization point during development towards a release. The beta release should have no known defects based on unit tests and local development, but has not yet gone through extensive integration testing, nor testing in the "real world" in public networks (e.g. Mainnet and parallel networks / altnets).

Pre-release

• Your changes should be on a branch.
• Your changes should have unit tests.
• Build your code.
• Run the unit tests.
• Get a full code review.
• Wait for a releaser to include your PR in a beta release.

Release

• In the release notes, ensure there is a dedicated section outlining the names of new amendments that are introduced.
• Try to credit issue reporters on a best-effort basis. As there is no automatic tracking of reporters, this is a manual process and prone to errors. But in general, we make every effort to give credit to reporters of valid issues.
• Share release notes with the docs team.
• Bump the version number with a commit that has the message: "Set version to " (example). You may include the release notes (RELEASENOTES.md) in this commit.
• Open "Proposed x.y.z" PR (example).
• Have team members complete release checks: on all supported OSes, ensure tests pass and syncing works.
• Fast-forward merge the PR branch and push to github (develop, release. And for a stable release, master as well).
• Create a release on github with an appropriate tag name (the version number).
• Post the release notes on the XRPL Dev Blog (with docs team).
• Open a PR to update the docs as appropriate.
• Send an announcement message to ripple-server.
• Update altnet (Testnet) and Devnet servers. Internal to Ripple: open a ticket in IN/INS (Infrastructure). Update other servers depending on the type of release (e.g. stable releases should be deployed to Mainnet servers).