From 211a07d1a18b326c8d6b3285e0b4ddf681fd50cf Mon Sep 17 00:00:00 2001 From: Laurent Senta Date: Wed, 21 Sep 2022 17:51:20 +0200 Subject: [PATCH 01/15] DESIGN.md: add process design doc --- DESIGN.md | 148 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 148 insertions(+) create mode 100644 DESIGN.md diff --git a/DESIGN.md b/DESIGN.md new file mode 100644 index 000000000..8e87f56de --- /dev/null +++ b/DESIGN.md @@ -0,0 +1,148 @@ +# libp2p testing story + +| Status | Draft | +| Created | 2022-09-09 | +| Approved | Pending… | + +--- + +## Overview + +This document describes our process for testing interoperability & backward compatibility in libp2p. + +**Why care about this:** + +- Interoperability is a shared problem + - we don’t have a single blessed reference implementation that we use for conformance testing. + - No single maintainer (whether libp2p or ipdx) will succeed without everyone's involvement. +- We want to share a Testing Story with the world that shows we care about quality & interop. +- We want to encourage other implementations to join the testing party. + +**Context:** + +- We completed a “PING” interop test with Testground. It is running in go and rust-libp2p CIs. +- It means we “proved” that we can write and run interop tests between versions AND implementation. + +# Libp2p Testing Matrix + +*What do we want to test next?* + +| | go-libp2p | rust-libp2p | js-libp2p (node) | js-libp2p (browser) | jvm-libp2p | nim-libp2p | +| --- | --- | --- | --- | --- | --- | --- | +| Simple PING [#35][issue-35] | ✅ | ✅ | 🍎 | 🔥 | | | +| Circuit Relay | | | | | | | +| WebTransport Transport | 🔥 | 🔥 | 🔥 | 🔥 | | | +| WebRTC Transport | 🔥 | 🔥 | 🔥 | 🔥 | | | +| NAT Traversal | | | | | | | +| Hole Punching (STUN) | | | | | | | +| Identify Protocol | | | | | | | +| AutoNAT | | | | | | | +| DHT | | | | | | | +| QUIC | | | | | | | +| Benchmarking? | | | | | | | + +**Dependencies** + +- Anything `js-libp2p` related requires the `ping` test to start +- Benchmarking must relate to [Remote Runners][remote-runners] + +**Questions** + +- When do we revisit this table to discuss priorities and add new tests? + +**Legend** + +- ✅ Done +- 🚚 In Progress +- 🔥 Highest Priority +- 🍎 Low-hanging fruit +- 🧊 Lowest priority + +# How do we test libp2p interop at ProtocolLabs? + +*(this is pretty much what happen with the go|rust-libp2p ping tests)* + +I (laurent) haven’t had time to look at [libp2p/interop](https://github.com/libp2p/interop/actions/runs/3021456724) yet. Some information may be missing. + + + +**Example:** + +- [IPFS Test Story in libp2p/interop](https://github.com/libp2p/interop/blob/master/pdd/PDD-THE-IPFS-BUNDLE.md) + +**Question:** + +- What should be the format for this description? +- Can we live with a rough “here is a general idea of what the test should do”, and let the first implementor figure out the details? +- Do we need to make these decisions now? (09-09-2022) + + + +**Example:** + +- https://github.com/libp2p/test-plans/pull/9 “add an instructional libp2p ping test plan” + +**Why:** + +- During implementation, some decisions might be taken on how coordination works, details of the tests, etc. It will be easier to clear the path from one implementation. + + + +**Example:** + +- https://github.com/libp2p/go-libp2p/pull/1625 “ci: run testground:ping plan on pull requests” in go-libp2p + + + +**Example:** + +- https://github.com/libp2p/test-plans/pull/26 “ping/rust: introduce rust cross-version test” +- https://github.com/libp2p/rust-libp2p/pull/2835 “.github: introduce interop tests” in rust-libp2p + + + +**Example:** + +- TODO: add the `full` interop test to `go-libp2p` + update their release documentation. + +## Questions + +- When do we revisit this scenario to improve and gather feedback? + - How do we evaluate progress & success? + - When we’re able to use these tests for benchmarking probably. + - What’s the plan for the day when everything starts to break? + - What’s the plan for the time when we start to crumble under test complexity? +- Maintenance + - Tests will need updates on new releases, etc. +- What are the dependencies between tests? + - ex: Does it make sense to test HOLE PUNCHING if you don’t test AUTONAT first? + +## Refs + +detrimental + +- [https://docs.libp2p.io/concepts/protocols/](https://docs.libp2p.io/concepts/protocols/) +- libp2p interop in [Interop Repository](https://github.com/libp2p/interop) +- [libp2p interop issue](https://github.com/libp2p/interop/issues/70) +- [libp2p/interop test plans](https://github.com/libp2p/interop/blob/master/pdd/PDD-THE-IPFS-BUNDLE.md) + + +[issue-35]: https://github.com/libp2p/test-plans/issues/35 +[remote-runners]: https://pl-strflt.notion.site/Remote-Runners-c4ad4886c4294fb6a6f8afd9c0c5b73c \ No newline at end of file From 7bb09a37b21b15664c13cbeae1f949ecb8c19891 Mon Sep 17 00:00:00 2001 From: Laurent Senta Date: Mon, 26 Sep 2022 16:32:28 +0200 Subject: [PATCH 02/15] DESIGN.md: clean header --- DESIGN.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/DESIGN.md b/DESIGN.md index 8e87f56de..a7dbe51b8 100644 --- a/DESIGN.md +++ b/DESIGN.md @@ -1,8 +1,6 @@ # libp2p testing story -| Status | Draft | -| Created | 2022-09-09 | -| Approved | Pending… | +- Status: Draft --- From 0e4e43c8bbd437d89763fb5d80a9789ae4b1cab6 Mon Sep 17 00:00:00 2001 From: Laurent Senta Date: Mon, 26 Sep 2022 16:32:43 +0200 Subject: [PATCH 03/15] ROADMAP.md: create roadmap file --- ROADMAP.md | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 ROADMAP.md diff --git a/ROADMAP.md b/ROADMAP.md new file mode 100644 index 000000000..a00a12282 --- /dev/null +++ b/ROADMAP.md @@ -0,0 +1,58 @@ +# Short Term +(getting ready for lab days) + +## Outcome: + +- The repository covers: + - (rust, go, nodejs, browserjs) x (ping test) +- We have a working demonstration + presentation for the event +- We have a single Dashboard to track the current state of interop testing + + +## EPICs + +- There is a clear way to tell the state of libp2p's interoperability testing + - Create a page that tells me which implementations are supported by our interop infrastructure + - This page tells us combination of test is not implemented / implemented / broken / passing + - (LATER) This page is generated automatically +- The `lip2p/interop` test suite covers essential features for the demonstration + - browserjs + - nodejs + - webtransport + - webrtc +- The full `libp2p/interop` test suite is used before releasing any new versions + - Go + Rust + JS libp2p release processes contains a call to this workflow + - This workflow might be enabled for nightly runs +- The light `libp2p/interop` testsuite is used with every new Pull Request + - This make sure we keep the test green +- We fixed every known stability issues with the `libp2p/interop` testsuite + - TODO: list here + + +# Medium Term + +## EPICs + +- We have a clear way to track the testsuite stability and performances + - We can track the status of every test combination stability from the interop project itself + - We can easily measure the consequence (improvements) of a pull request to the libp2p/interop repository + - We are alerted when an interop test starts failing on one of our client repository and we can dispatch the alert to a repo maintainers or fix it ourselves. +- We have an explicit, working, Design Process for adding new tests + - The design is documented in + - The design is used by the team when we add new features + - There are clear path when it comes to testing new features. This might mean testing multiple `master` against each other. +- We have a more stable build process that don't risk breaking + - We generate artifacts for old versions during merges to the libp2p repositories https://github.com/libp2p/test-plans/issues/35#issuecomment-1254991985 + + +# Long Term + +## EPICs + +- Libp2p interop covers essential features and implementations + - NAT Traversal +- Libp2p interop is used to test new features + - The design process is clear and well defined +- Libp2p interop and libp2p test-plans are working together + - Either merged as one + - or "sync'd" From 70f8e08d6c592d9a456b779d6783c82048285063 Mon Sep 17 00:00:00 2001 From: Laurent Senta Date: Mon, 26 Sep 2022 16:54:33 +0200 Subject: [PATCH 04/15] ROADMAP.md: add a few details --- ROADMAP.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/ROADMAP.md b/ROADMAP.md index a00a12282..37393dbe7 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -41,18 +41,21 @@ - The design is documented in - The design is used by the team when we add new features - There are clear path when it comes to testing new features. This might mean testing multiple `master` against each other. -- We have a more stable build process that don't risk breaking - - We generate artifacts for old versions during merges to the libp2p repositories https://github.com/libp2p/test-plans/issues/35#issuecomment-1254991985 # Long Term ## EPICs +- The Libp2p Team is using remote runners for benchmarking - Libp2p interop covers essential features and implementations - - NAT Traversal + - NAT Traversal / Hole Punching + - Custom Topologies + - MTU Fixes - Libp2p interop is used to test new features - The design process is clear and well defined - Libp2p interop and libp2p test-plans are working together - Either merged as one - or "sync'd" +- We have a more stable build process that don't risk breaking + - We generate artifacts for old versions during merges to the libp2p repositories https://github.com/libp2p/test-plans/issues/35#issuecomment-1254991985 \ No newline at end of file From f32bfb2bd25b8188b4514dac1ef1ba1ec09af33f Mon Sep 17 00:00:00 2001 From: Laurent Senta Date: Tue, 27 Sep 2022 11:22:29 +0200 Subject: [PATCH 05/15] ROADMAP.md: add more details --- ROADMAP.md | 58 ++++++++++++++++++++++++++---------------------------- 1 file changed, 28 insertions(+), 30 deletions(-) diff --git a/ROADMAP.md b/ROADMAP.md index 37393dbe7..65c1d5c1a 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -4,44 +4,43 @@ ## Outcome: - The repository covers: - - (rust, go, nodejs, browserjs) x (ping test) -- We have a working demonstration + presentation for the event + - (rust, go, nodejs, browserjs) x (ping test) +- We have a working demonstration and a presentation for the event - We have a single Dashboard to track the current state of interop testing ## EPICs - There is a clear way to tell the state of libp2p's interoperability testing - - Create a page that tells me which implementations are supported by our interop infrastructure - - This page tells us combination of test is not implemented / implemented / broken / passing - - (LATER) This page is generated automatically + - Create a page that tells me which implementations are supported by our interop infrastructure, + - This page signal the status of each test (not implemented / implemented / broken / passing) + - This page is generated automatically, nightly - The `lip2p/interop` test suite covers essential features for the demonstration - - browserjs - - nodejs - - webtransport - - webrtc + - browserjs + - nodejs + - webtransport + - webrtc - The full `libp2p/interop` test suite is used before releasing any new versions - - Go + Rust + JS libp2p release processes contains a call to this workflow - - This workflow might be enabled for nightly runs -- The light `libp2p/interop` testsuite is used with every new Pull Request - - This make sure we keep the test green -- We fixed every known stability issues with the `libp2p/interop` testsuite - - TODO: list here + - Go + Rust + JS libp2p release processes contain a call to this workflow + - Maintainers might enable this workflow for nightly runs +- The light `libp2p/interop` test suite is used with every new Pull Request + - This makes sure we keep the test green +- We fixed every known stability issue with the `libp2p/interop` test suite + - [Issue 36](https://github.com/libp2p/test-plans/issues/36) # Medium Term ## EPICs -- We have a clear way to track the testsuite stability and performances - - We can track the status of every test combination stability from the interop project itself - - We can easily measure the consequence (improvements) of a pull request to the libp2p/interop repository - - We are alerted when an interop test starts failing on one of our client repository and we can dispatch the alert to a repo maintainers or fix it ourselves. +- `libp2p/test-plans` maintainers have a straightforward way to track the test suite stability and performances + - We can track the status of every test combination stability from the interop project itself + - We can easily measure the consequence (improvements) of a pull request to the libp2p/interop repository + - We are alerted when an interop test starts failing on one of our client repositories, and we can dispatch the alert to repo maintainers, - We have an explicit, working, Design Process for adding new tests - - The design is documented in - - The design is used by the team when we add new features - - There are clear path when it comes to testing new features. This might mean testing multiple `master` against each other. - + - The design is documented in `./ROADMAP.md`, + - The design is followed by the team when we add new features, + - There is a clear path when it comes to testing new features. This might mean testing multiple `masters` against each other. # Long Term @@ -49,13 +48,12 @@ - The Libp2p Team is using remote runners for benchmarking - Libp2p interop covers essential features and implementations - - NAT Traversal / Hole Punching + - NAT Traversal / Hole Punching - Custom Topologies - MTU Fixes - Libp2p interop is used to test new features - - The design process is clear and well defined -- Libp2p interop and libp2p test-plans are working together - - Either merged as one - - or "sync'd" -- We have a more stable build process that don't risk breaking - - We generate artifacts for old versions during merges to the libp2p repositories https://github.com/libp2p/test-plans/issues/35#issuecomment-1254991985 \ No newline at end of file + - The design process is clear and well defined +- `libp2p/interop` and `libp2p/test-plans` are working together + - They are either merged or somehow know about each other. +- We have a more stable build process that doesn't risk breaking + - We generate artifacts for old versions during merges to the libp2p repositories https://github.com/libp2p/test-plans/issues/35#issuecomment-1254991985 \ No newline at end of file From b7813733e2de794e292a5dcbfdd87d659247cde1 Mon Sep 17 00:00:00 2001 From: Laurent Senta Date: Tue, 27 Sep 2022 11:28:08 +0200 Subject: [PATCH 06/15] ROADMAP.md: (almost) align the table --- DESIGN.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/DESIGN.md b/DESIGN.md index a7dbe51b8..a396d7b86 100644 --- a/DESIGN.md +++ b/DESIGN.md @@ -27,17 +27,17 @@ This document describes our process for testing interoperability & backward comp | | go-libp2p | rust-libp2p | js-libp2p (node) | js-libp2p (browser) | jvm-libp2p | nim-libp2p | | --- | --- | --- | --- | --- | --- | --- | -| Simple PING [#35][issue-35] | ✅ | ✅ | 🍎 | 🔥 | | | -| Circuit Relay | | | | | | | -| WebTransport Transport | 🔥 | 🔥 | 🔥 | 🔥 | | | -| WebRTC Transport | 🔥 | 🔥 | 🔥 | 🔥 | | | -| NAT Traversal | | | | | | | -| Hole Punching (STUN) | | | | | | | -| Identify Protocol | | | | | | | -| AutoNAT | | | | | | | -| DHT | | | | | | | -| QUIC | | | | | | | -| Benchmarking? | | | | | | | +| Simple PING [#35][issue-35] | ✅ | ✅ | 🍎 | 🔥 | | | +| Circuit Relay | | | | | | | +| WebTransport Transport | 🔥 | 🔥 | 🔥 | 🔥 | 🔥 | 🔥 | +| WebRTC Transport | 🔥 | 🔥 | 🔥 | 🔥 | 🔥 | 🔥 | +| NAT Traversal | | | | | | | +| Hole Punching (STUN) | | | | | | | +| Identify Protocol | | | | | | | +| AutoNAT | | | | | | | +| DHT | | | | | | | +| QUIC | | | | | | | +| Benchmarking? | | | | | | | **Dependencies** From c3bd3b6d8e9d40e03c995f6f5544428ba5a2c42e Mon Sep 17 00:00:00 2001 From: Laurent Senta Date: Tue, 27 Sep 2022 11:28:27 +0200 Subject: [PATCH 07/15] ROADMAP.md: remove the "detrimental" note --- DESIGN.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/DESIGN.md b/DESIGN.md index a396d7b86..44034abc9 100644 --- a/DESIGN.md +++ b/DESIGN.md @@ -134,8 +134,6 @@ It might be enabled in a nightly job too. ## Refs -detrimental - - [https://docs.libp2p.io/concepts/protocols/](https://docs.libp2p.io/concepts/protocols/) - libp2p interop in [Interop Repository](https://github.com/libp2p/interop) - [libp2p interop issue](https://github.com/libp2p/interop/issues/70) From a15c8efcb2b18f846d6063bf06f1372795cbe9ec Mon Sep 17 00:00:00 2001 From: Laurent Senta Date: Tue, 27 Sep 2022 11:42:25 +0200 Subject: [PATCH 08/15] ROADMAP.md: fix repo names + add notes on interop --- ROADMAP.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/ROADMAP.md b/ROADMAP.md index 65c1d5c1a..7a1852fed 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -15,17 +15,17 @@ - Create a page that tells me which implementations are supported by our interop infrastructure, - This page signal the status of each test (not implemented / implemented / broken / passing) - This page is generated automatically, nightly -- The `lip2p/interop` test suite covers essential features for the demonstration +- The `lip2p/test-plans` test suite covers essential features for the demonstration - browserjs - nodejs - webtransport - webrtc -- The full `libp2p/interop` test suite is used before releasing any new versions +- The full `libp2p/test-plans` test suite is used before releasing any new versions - Go + Rust + JS libp2p release processes contain a call to this workflow - Maintainers might enable this workflow for nightly runs -- The light `libp2p/interop` test suite is used with every new Pull Request +- The light `libp2p/test-plans` test suite is used with every new Pull Request - This makes sure we keep the test green -- We fixed every known stability issue with the `libp2p/interop` test suite +- We fixed every known stability issue with the `libp2p/test-plans` test suite - [Issue 36](https://github.com/libp2p/test-plans/issues/36) @@ -41,6 +41,9 @@ - The design is documented in `./ROADMAP.md`, - The design is followed by the team when we add new features, - There is a clear path when it comes to testing new features. This might mean testing multiple `masters` against each other. +- We have ported the tests from `libpp2/interop` + - This repository implement tests `connect`, `dht`, `pubsub`, `steam` ([ref](https://github.com/libp2p/interop/blob/ce0aa3749c9c53cf5ad53009b273847b94106d40/src/index.ts#L32-L35)) + - At of writing (2022-09-27), it is disabled in `go-libp2p` ([ref](https://github.com/libp2p/go-libp2p/actions/workflows/interop.yml)), and it is used in `js-libp2p` ([ref](https://github.com/libp2p/js-libp2p/actions/runs/3111413168/jobs/5050929689)). # Long Term From f8cf56b0ae6739d5cbd13c5e640d513012d37654 Mon Sep 17 00:00:00 2001 From: Prithvi Shahi <50885601+p-shahi@users.noreply.github.com> Date: Thu, 20 Oct 2022 09:10:09 -0700 Subject: [PATCH 09/15] update roadmap (#56) --- DESIGN.md | 26 ++++-- ROADMAP.md | 249 ++++++++++++++++++++++++++++++++++++++++------------- 2 files changed, 204 insertions(+), 71 deletions(-) diff --git a/DESIGN.md b/DESIGN.md index 44034abc9..b7f6d7a76 100644 --- a/DESIGN.md +++ b/DESIGN.md @@ -1,25 +1,28 @@ # libp2p testing story -- Status: Draft +``` +Date: 2022-10-18 +Status: In Progress +``` --- ## Overview -This document describes our process for testing interoperability & backward compatibility in libp2p. +This document describes our process for testing interoperability & backward compatibility across libp2p implementations. -**Why care about this:** +**Why:** -- Interoperability is a shared problem - - we don’t have a single blessed reference implementation that we use for conformance testing. - - No single maintainer (whether libp2p or ipdx) will succeed without everyone's involvement. +- Interoperability is a shared concern. +- There is no single blessed libp2p reference implementation that we use for conformance testing. +- No single maintainer (go|rust|js-libp2p or IPDX) will succeed without everyone's involvement. - We want to share a Testing Story with the world that shows we care about quality & interop. - We want to encourage other implementations to join the testing party. -**Context:** +**Historical Context:** -- We completed a “PING” interop test with Testground. It is running in go and rust-libp2p CIs. -- It means we “proved” that we can write and run interop tests between versions AND implementation. +- We completed a “PING” interop test with Testground. It is running in the go-libp2p and rust-libp2p CI pipeline. +- It means we “proved” that we can write and run interop tests between versions AND implementations. # Libp2p Testing Matrix @@ -58,6 +61,11 @@ This document describes our process for testing interoperability & backward comp # How do we test libp2p interop at ProtocolLabs? +--- + +--- + + *(this is pretty much what happen with the go|rust-libp2p ping tests)* I (laurent) haven’t had time to look at [libp2p/interop](https://github.com/libp2p/interop/actions/runs/3021456724) yet. Some information may be missing. diff --git a/ROADMAP.md b/ROADMAP.md index 7a1852fed..329919c4a 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,62 +1,187 @@ -# Short Term -(getting ready for lab days) - -## Outcome: - -- The repository covers: - - (rust, go, nodejs, browserjs) x (ping test) -- We have a working demonstration and a presentation for the event -- We have a single Dashboard to track the current state of interop testing - - -## EPICs - -- There is a clear way to tell the state of libp2p's interoperability testing - - Create a page that tells me which implementations are supported by our interop infrastructure, - - This page signal the status of each test (not implemented / implemented / broken / passing) - - This page is generated automatically, nightly -- The `lip2p/test-plans` test suite covers essential features for the demonstration - - browserjs - - nodejs - - webtransport - - webrtc -- The full `libp2p/test-plans` test suite is used before releasing any new versions - - Go + Rust + JS libp2p release processes contain a call to this workflow - - Maintainers might enable this workflow for nightly runs -- The light `libp2p/test-plans` test suite is used with every new Pull Request - - This makes sure we keep the test green -- We fixed every known stability issue with the `libp2p/test-plans` test suite - - [Issue 36](https://github.com/libp2p/test-plans/issues/36) - - -# Medium Term - -## EPICs - -- `libp2p/test-plans` maintainers have a straightforward way to track the test suite stability and performances - - We can track the status of every test combination stability from the interop project itself - - We can easily measure the consequence (improvements) of a pull request to the libp2p/interop repository - - We are alerted when an interop test starts failing on one of our client repositories, and we can dispatch the alert to repo maintainers, -- We have an explicit, working, Design Process for adding new tests - - The design is documented in `./ROADMAP.md`, - - The design is followed by the team when we add new features, - - There is a clear path when it comes to testing new features. This might mean testing multiple `masters` against each other. -- We have ported the tests from `libpp2/interop` - - This repository implement tests `connect`, `dht`, `pubsub`, `steam` ([ref](https://github.com/libp2p/interop/blob/ce0aa3749c9c53cf5ad53009b273847b94106d40/src/index.ts#L32-L35)) - - At of writing (2022-09-27), it is disabled in `go-libp2p` ([ref](https://github.com/libp2p/go-libp2p/actions/workflows/interop.yml)), and it is used in `js-libp2p` ([ref](https://github.com/libp2p/js-libp2p/actions/runs/3111413168/jobs/5050929689)). - -# Long Term - -## EPICs - -- The Libp2p Team is using remote runners for benchmarking -- Libp2p interop covers essential features and implementations - - NAT Traversal / Hole Punching - - Custom Topologies - - MTU Fixes -- Libp2p interop is used to test new features - - The design process is clear and well defined -- `libp2p/interop` and `libp2p/test-plans` are working together - - They are either merged or somehow know about each other. -- We have a more stable build process that doesn't risk breaking - - We generate artifacts for old versions during merges to the libp2p repositories https://github.com/libp2p/test-plans/issues/35#issuecomment-1254991985 \ No newline at end of file +# test-plans roadmap Q4’22/Q1’23 + +``` +Date: 2022-10-18 +Status: In Progress +Notes: This document is still in review will may be heavily modified based on stakeholder feedback. Please add any feedback or questions in: +https://github.com/libp2p/test-plans/issues/58 +``` + +## Table of Contents + +- [About the Roadmap](#about-the-roadmap) + - [Vision](#vision) + - [Sections](#sections) +- [🛣️ Milestones](#️-milestones) + - [2022](#2022) + - [Early Q4 (October)](#early-q4-october) + - [Mid Q4 (November)](#mid-q4-november) + - [End of Q4 (December)](#end-of-q4-december) + - [2023](#2023) + - [Early Q1 (January)](#early-q1-january) + - [End of Q1 (March)](#end-of-q1-march) + - [Up Next](#up-next) +- [📖 Appendix](#-appendix) + - [A. Multi-dimensional Testing/Interop Visibility](#a-multi-dimensional-testinginterop-visibility) + - [1. User configured interop tests & dashboard](#1-user-configured-interop-tests--dashboard) + - [2. Interop test plans for all existing/developing libp2p transports](#2-interop-test-plans-for-all-existingdeveloping-libp2p-transports) + - [3. Canonical interop tests & dashboard](#3-canonical-interop-tests--dashboard) + - [B. Hardening test infrastructure](#b-hardening-test-infrastructure) + - [1. Track test suite stability](#1-track-test-suite-stability) + - [2. Design process for adding new tests](#2-design-process-for-adding-new-tests) + - [3. Be the home for all interop tests](#3-be-the-home-for-all-interop-tests) + - [C. Future-proof Benchmarking](#c-future-proof-benchmarking) + - [1. Benchmarking using nix-builders](#1-benchmarking-using-nix-builders) + - [2. Benchmarking using remote runners](#2-benchmarking-using-remote-runners) + - [D. Expansive protocol test coverage](#d-expansive-protocol-test-coverage) + - [1. DHT server mode scale test](#1-dht-server-mode-scale-test) + - [2. AutoNat](#2-autonat) + - [3. Hole Punching](#3-hole-punching) + - [4. AutoRelay](#4-autorelay) + - [5. Custom topologies](#5-custom-topologies) + - [6. MTU Fixes](#6-mtu-fixes) + +## About the Roadmap + +### Vision +We, the maintainers, are committed to upholding libp2p's shared core tenets and ensuring libp2p implementations are: [**Secure, Stable, Specified, and Performant.**](https://github.com/libp2p/specs/blob/master/ROADMAP.md#core-tenets) + +This roadmap is complementary to those of [go-libp2p](https://github.com/libp2p/go-libp2p/blob/master/ROADMAP.md), [rust-libp2p](https://github.com/libp2p/rust-libp2p/pull/2997), and [js-libp2p](https://github.com/libp2p/js-libp2p/pull/1412). + +It aims to encompass the **stability** and **performance** tenets of the libp2p team. +Projects outlined here are shared priorities of the different implementations. + +### Sections +This document consists of two sections: [Milestones](#️-milestones) and the [Appendix](#-appendix) + +[Milestones](#️-milestones) is our best educated guess (not a hard commitment) around when we plan to ship the key features. +Where possible projects are broken down into discrete sub-projects e.g. project "A" may contain two sub-projects: A.1 and A.2 + +A project is signified as "complete" once all of it's sub-projects are shipped. + +The [Appendix](#-appendix) section describes a project's high-level motivation, goals, and lists sub-projects. + +Each Appendix header is linked to a GitHub Epic. Latest information on progress can be found in the Epics and child issues. + +## 🛣️ Milestones + +### 2022 + +#### Early Q4 (October) +- [A.1 User Configured Interop Tests & Dashboard](#1-user-configured-interop-tests--dashboard) + +#### Mid Q4 (November) +- [A.2 Interop tests for all existing/developing libp2p transports](#2-interop-test-plans-for-all-existingdeveloping-libp2p-transports) +- [C.1 Benchmarking using nix-builders](#1-benchmarking-using-nix-builders) + +#### End of Q4 (December) +- [A.3 Canonical Interop Tests & Dashboard](#3-canonical-interop-tests--dashboard) + +### 2023 + +#### Early Q1 (January) + +- [D.1 DHT Server Mode Scale Test](#1-dht-server-mode-scale-test) + +#### End of Q1 (March) +- [C.2 Benchmarking using remote runners](#2-benchmarking-using-remote-runners) + +### Up Next + +## 📖 Appendix + +**Projects are listed in descending priority.** + +### A. [Multi-dimensional Testing/Interop Visibility](https://github.com/libp2p/test-plans/issues/53) +**Why:** libp2p supports a variety of transport protocols, muxers, & security protocols across implementations in different languages. Until we actually test them together, we can't guarantee implementation interoperability. We need to ensure and demonstrate that: interoperable features work with each other as expected and we don't introduce degradations that break interoperability in new releases. + +**Goal:** libp2p implementers run tests across permutations of libp2p implementations, versions, and supported transports, muxers, and security protocols. Implementers and users can reference a single website with a dashboard to view the Pass/Fail/Implemented/Not Implemented results of multi-dimensional tests. + +This effort depends on [Testground Milestone 1](https://github.com/testground/testground/blob/master/ROADMAP.md#1-bootstrap-libp2ps-interoperability-testing-story) + +**How:** +#### 1. [User configured interop tests & dashboard](https://github.com/libp2p/test-plans/issues/55) +Enable test-plans maintainers to define a configuration (of libp2p impls, versions, transports, expected RTT), run Testground tests per configuration, and retrieve resulting data in a standard format. +The test case results can be formatted as a "dashboard" (simple Markdown table of Pass/Fail results.) + +#### 2. Interop test plans for all existing/developing libp2p transports + +Using tooling from A.1, all features of go-libp2p, rust-libp2p, and js-libp2p that should be interoperable are tested (i.e. transports (TCP, QUIC, WebRTC, WebTransport), multiplexers (mplex, yamux), secure channels (TLS, Noise), etc.) across versions. + +Features currently in development across implementations (like WebRTC in go-libp2p and rust-libp2p, or QUIC & TLS in rust-libp2p) are not merged without at least manually running these test suites. + +Test suites are run in `libp2p/test-plans` CI and before releasing a version of go-libp2p, rust-libp2p, and js-libp2p (GitHub workflow added so that these suites run against the `master` branch on a nightly basis (updating the status check.)) + +**Note:** +- Dependency on [C.1](#1-benchmarking-using-nix-builders) to run node.js-libp2p in Testground. +- Dependency on [testground/Investigate browser test support](https://github.com/testground/testground/issues/1386) to run interoperability test for js-libp2p WebRTC against Go and Rust. + +#### 3. Canonical interop tests & dashboard + +A comprehensive and canonical dashboard is generated and hosted in a publicly discoverable site that displays latest test suite results (Pass/Fail/Implemented/Not Implemented/Unimplementable) from a nightly CI run. +All permutations of libp2p implementations, versions, and supported transports, muxers, & security protocols should be visible. + +An enhancement of A.1 to make it easier for users and implementers to see the full state of libp2p interoperability. + +### B. Hardening test infrastructure + +#### 1. Track test suite stability + + +`libp2p/test-plans` maintainers have a straightforward way to track the test suite stability and performance. +- We can track the status of every test combination stability from the interop project itself +- We can easily measure the consequence (improvements) of a pull request to the libp2p/interop repository +- We are alerted when an interop test starts failing on one of our client repositories, and we can dispatch the alert to repo maintainers. + +#### 2. Design process for adding new tests + + +We have an explicit, working, Design Process for adding new tests +- The design is documented in `./DESIGN.md`. +- The design is followed by the team when we add new features. +- There is a clear path when it comes to testing new features. This might mean testing multiple `masters` against each other. + +#### 3. Be the home for all interop tests + + +We have ported the tests from `libp2p/interop` +- This repository implement tests `connect`, `dht`, `pubsub` ([ref](https://github.com/libp2p/interop/blob/ce0aa3749c9c53cf5ad53009b273847b94106d40/src/index.ts#L32-L35)) +- At of writing (2022-09-27), it is disabled in `go-libp2p` ([ref](https://github.com/libp2p/go-libp2p/actions/workflows/interop.yml)), and it is used in `js-libp2p` ([ref](https://github.com/libp2p/js-libp2p/actions/runs/3111413168/jobs/5050929689)). + + +### [C. Future-proof Benchmarking](https://github.com/libp2p/go-libp2p/issues/1810) +**Why**: For libp2p to be competitive, it needs to delivers comparable performance to widely used protocols on the internet, namely HTTP/2 and HTTP/3. + +**Goal**: We have a test suite that runs libp2p transfers between nodes located at different locations all over the world, proving that libp2p is able to achieve performance on par with HTTP. The test suite is run on a continuous basis and results are published to a public performance dashboard. + +#### 1. [Benchmarking using nix-builders](https://github.com/testground/testground/pull/1425) +- Benchmark go-libp2p, rust-libp2p, and go-libp2p +- Specifically add [js-libp2p-transfer-performance](https://github.com/ipfs-shipyard/js-libp2p-transfer-performance) as a test-plan and CI job to benchmark transfer times across releases to catch issues like [#1342](https://github.com/libp2p/js-libp2p/issues/1342) +- (Dependency: remote machines need Nix installed) +#### 2. Benchmarking using remote runners +Benchmarking using first class support for remote runners (using `remote:exec`) in Testground + + +### D. Expansive protocol test coverage + + +**Why:** Having interoperability tests with lots of transports, encryption mechanisms, and stream muxers is great. However, we need to stay backwards-compatible with legacy libp2p releases, with other libp2p implementations, and less advanced libp2p stacks. + +**Goal:** Expand beyond unit tests and have expansive test-plan coverage that covers all protocols. + +This effort depends on [Testground Milestone 6](https://github.com/testground/testground/blob/master/ROADMAP.md#6-support-libp2ps-interoperability-testing-story-and-probelabs-work-as-a-way-to-drive-critical-testground-improvements) + + +#### 1. DHT server mode scale test +Test js-libp2p DHT Server Mode at scale (testbed of at least >20 nodes; ideally 100/1000+) in Testground +Depends on [C.1](#1-benchmarking-using-nix-builders) +Relates to [Testground Milestone 4 (for large scale tests.)](https://github.com/testground/testground/blob/master/ROADMAP.md#4-provide-a-testground-as-a-service-cluster-used-by-libp2p--ipfs-teams) +#### 2. AutoNat +Depends on [testground/NAT and/or firewall support](https://github.com/testground/testground/issues/1299) +#### 3. Hole Punching +Depends on [testground/NAT and/or firewall support](https://github.com/testground/testground/issues/1299) +#### 4. AutoRelay +#### 5. Custom topologies +#### 6. MTU Fixes +Depends on [testground/Network Simulation Fixes](https://github.com/testground/testground/issues/1492) From 0aa311b99c0ac196931675c1bdd7b9ed544f1a20 Mon Sep 17 00:00:00 2001 From: Prithvi Shahi <50885601+p-shahi@users.noreply.github.com> Date: Thu, 20 Oct 2022 09:34:22 -0700 Subject: [PATCH 10/15] Apply suggestions from code review Co-authored-by: Steve Loeppky --- DESIGN.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/DESIGN.md b/DESIGN.md index b7f6d7a76..0a2ff13cb 100644 --- a/DESIGN.md +++ b/DESIGN.md @@ -32,8 +32,8 @@ This document describes our process for testing interoperability & backward comp | --- | --- | --- | --- | --- | --- | --- | | Simple PING [#35][issue-35] | ✅ | ✅ | 🍎 | 🔥 | | | | Circuit Relay | | | | | | | -| WebTransport Transport | 🔥 | 🔥 | 🔥 | 🔥 | 🔥 | 🔥 | -| WebRTC Transport | 🔥 | 🔥 | 🔥 | 🔥 | 🔥 | 🔥 | +| WebTransport Transport | 🔥 | | 🔥 (depends on https://github.com/libp2p/js-libp2p-webtransport/issues/1) | 🔥 (depends on https://github.com/libp2p/js-libp2p-webtransport/issues/1) | | | +| WebRTC Transport | 🔥 (depends on working implementation) | 🔥 (depends on working implementation) | 🔥 (depends on working implementation) | 🔥 (depends on working implementation) | | | | NAT Traversal | | | | | | | | Hole Punching (STUN) | | | | | | | | Identify Protocol | | | | | | | @@ -59,19 +59,23 @@ This document describes our process for testing interoperability & backward comp - 🍎 Low-hanging fruit - 🧊 Lowest priority -# How do we test libp2p interop at ProtocolLabs? +# How does libp2p test interoperability? --- --- -*(this is pretty much what happen with the go|rust-libp2p ping tests)* +## Background +The approach outlined below is pretty much what happen with the go|rust-libp2p ping tests in 2022Q3. -I (laurent) haven’t had time to look at [libp2p/interop](https://github.com/libp2p/interop/actions/runs/3021456724) yet. Some information may be missing. +libp2p implementations aren't forced to adopt this approach, but it is the approach that has been taken by some of the longer-lived implementations (go, JS, and rust). +I (@laurent) haven’t had time to look at [libp2p/interop](https://github.com/libp2p/interop/actions/runs/3021456724) yet. Some information may be missing. + +## 202210 Proposal @@ -128,7 +132,7 @@ It might be enabled in a nightly job too. - TODO: add the `full` interop test to `go-libp2p` + update their release documentation. -## Questions +## Open Questions - When do we revisit this scenario to improve and gather feedback? - How do we evaluate progress & success? From 2ac09ba160bb3d50882d150ea1a1905f9d363831 Mon Sep 17 00:00:00 2001 From: Prithvi Shahi Date: Thu, 20 Oct 2022 16:55:55 -0700 Subject: [PATCH 11/15] add issue link --- ROADMAP.md | 31 +++++++++++++------------------ 1 file changed, 13 insertions(+), 18 deletions(-) diff --git a/ROADMAP.md b/ROADMAP.md index 329919c4a..3218b779f 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -2,8 +2,8 @@ ``` Date: 2022-10-18 -Status: In Progress -Notes: This document is still in review will may be heavily modified based on stakeholder feedback. Please add any feedback or questions in: +Status: Accepted +Notes: Internal test-plans stakeholders have aligned on this roadmap. Please add any feedback or questions in: https://github.com/libp2p/test-plans/issues/58 ``` @@ -46,7 +46,7 @@ https://github.com/libp2p/test-plans/issues/58 ### Vision We, the maintainers, are committed to upholding libp2p's shared core tenets and ensuring libp2p implementations are: [**Secure, Stable, Specified, and Performant.**](https://github.com/libp2p/specs/blob/master/ROADMAP.md#core-tenets) -This roadmap is complementary to those of [go-libp2p](https://github.com/libp2p/go-libp2p/blob/master/ROADMAP.md), [rust-libp2p](https://github.com/libp2p/rust-libp2p/pull/2997), and [js-libp2p](https://github.com/libp2p/js-libp2p/pull/1412). +This roadmap is complementary to those of [go-libp2p](https://github.com/libp2p/go-libp2p/blob/master/ROADMAP.md), [rust-libp2p](https://github.com/libp2p/rust-libp2p/blob/master/ROADMAP.md), and [js-libp2p](https://github.com/libp2p/js-libp2p/blob/master/ROADMAP.md). It aims to encompass the **stability** and **performance** tenets of the libp2p team. Projects outlined here are shared priorities of the different implementations. @@ -92,7 +92,7 @@ Each Appendix header is linked to a GitHub Epic. Latest information on progress **Projects are listed in descending priority.** -### A. [Multi-dimensional Testing/Interop Visibility](https://github.com/libp2p/test-plans/issues/53) +### [A. Multi-dimensional Testing/Interop Visibility](https://github.com/libp2p/test-plans/issues/53) **Why:** libp2p supports a variety of transport protocols, muxers, & security protocols across implementations in different languages. Until we actually test them together, we can't guarantee implementation interoperability. We need to ensure and demonstrate that: interoperable features work with each other as expected and we don't introduce degradations that break interoperability in new releases. **Goal:** libp2p implementers run tests across permutations of libp2p implementations, versions, and supported transports, muxers, and security protocols. Implementers and users can reference a single website with a dashboard to view the Pass/Fail/Implemented/Not Implemented results of multi-dimensional tests. @@ -100,12 +100,11 @@ Each Appendix header is linked to a GitHub Epic. Latest information on progress This effort depends on [Testground Milestone 1](https://github.com/testground/testground/blob/master/ROADMAP.md#1-bootstrap-libp2ps-interoperability-testing-story) **How:** -#### 1. [User configured interop tests & dashboard](https://github.com/libp2p/test-plans/issues/55) +#### [1. User configured interop tests & dashboard](https://github.com/libp2p/test-plans/issues/55) Enable test-plans maintainers to define a configuration (of libp2p impls, versions, transports, expected RTT), run Testground tests per configuration, and retrieve resulting data in a standard format. The test case results can be formatted as a "dashboard" (simple Markdown table of Pass/Fail results.) -#### 2. Interop test plans for all existing/developing libp2p transports - +#### [2. Interop test plans for all existing/developing libp2p transports](https://github.com/libp2p/test-plans/issues/61) Using tooling from A.1, all features of go-libp2p, rust-libp2p, and js-libp2p that should be interoperable are tested (i.e. transports (TCP, QUIC, WebRTC, WebTransport), multiplexers (mplex, yamux), secure channels (TLS, Noise), etc.) across versions. Features currently in development across implementations (like WebRTC in go-libp2p and rust-libp2p, or QUIC & TLS in rust-libp2p) are not merged without at least manually running these test suites. @@ -116,8 +115,7 @@ Test suites are run in `libp2p/test-plans` CI and before releasing a version of - Dependency on [C.1](#1-benchmarking-using-nix-builders) to run node.js-libp2p in Testground. - Dependency on [testground/Investigate browser test support](https://github.com/testground/testground/issues/1386) to run interoperability test for js-libp2p WebRTC against Go and Rust. -#### 3. Canonical interop tests & dashboard - +#### [3. Canonical interop tests & dashboard](https://github.com/libp2p/test-plans/issues/62) A comprehensive and canonical dashboard is generated and hosted in a publicly discoverable site that displays latest test suite results (Pass/Fail/Implemented/Not Implemented/Unimplementable) from a nightly CI run. All permutations of libp2p implementations, versions, and supported transports, muxers, & security protocols should be visible. @@ -149,22 +147,19 @@ We have ported the tests from `libp2p/interop` - At of writing (2022-09-27), it is disabled in `go-libp2p` ([ref](https://github.com/libp2p/go-libp2p/actions/workflows/interop.yml)), and it is used in `js-libp2p` ([ref](https://github.com/libp2p/js-libp2p/actions/runs/3111413168/jobs/5050929689)). -### [C. Future-proof Benchmarking](https://github.com/libp2p/go-libp2p/issues/1810) +### [C. Future-proof Benchmarking](https://github.com/libp2p/test-plans/issues/63) **Why**: For libp2p to be competitive, it needs to delivers comparable performance to widely used protocols on the internet, namely HTTP/2 and HTTP/3. **Goal**: We have a test suite that runs libp2p transfers between nodes located at different locations all over the world, proving that libp2p is able to achieve performance on par with HTTP. The test suite is run on a continuous basis and results are published to a public performance dashboard. -#### 1. [Benchmarking using nix-builders](https://github.com/testground/testground/pull/1425) -- Benchmark go-libp2p, rust-libp2p, and go-libp2p -- Specifically add [js-libp2p-transfer-performance](https://github.com/ipfs-shipyard/js-libp2p-transfer-performance) as a test-plan and CI job to benchmark transfer times across releases to catch issues like [#1342](https://github.com/libp2p/js-libp2p/issues/1342) +#### [1. Benchmarking using nix-builders](https://github.com/testground/testground/pull/1425) +- [Benchmark go-libp2p, rust-libp2p, and go-libp2p](https://github.com/libp2p/test-plans/issues/27) +- [Specifically add js-libp2p-transfer-performance as a test-plan and CI job to benchmark transfer times across releases](https://github.com/libp2p/test-plans/issues/65) to catch issues like [#1342](https://github.com/libp2p/js-libp2p/issues/1342) - (Dependency: remote machines need Nix installed) -#### 2. Benchmarking using remote runners +#### [2. Benchmarking using remote runners](https://github.com/testground/testground/issues/1392) Benchmarking using first class support for remote runners (using `remote:exec`) in Testground - -### D. Expansive protocol test coverage - - +### [D. Expansive protocol test coverage](https://github.com/libp2p/test-plans/issues/64) **Why:** Having interoperability tests with lots of transports, encryption mechanisms, and stream muxers is great. However, we need to stay backwards-compatible with legacy libp2p releases, with other libp2p implementations, and less advanced libp2p stacks. **Goal:** Expand beyond unit tests and have expansive test-plan coverage that covers all protocols. From 62d19555253a7c7038a171f29b51a5e7b23b5008 Mon Sep 17 00:00:00 2001 From: Prithvi Shahi Date: Thu, 20 Oct 2022 17:17:33 -0700 Subject: [PATCH 12/15] update --- ROADMAP.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ROADMAP.md b/ROADMAP.md index 3218b779f..4946b1e93 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,9 +1,9 @@ # test-plans roadmap Q4’22/Q1’23 ``` -Date: 2022-10-18 +Date: 2022-10-20 Status: Accepted -Notes: Internal test-plans stakeholders have aligned on this roadmap. Please add any feedback or questions in: +Notes: Internal test-plans maintainers stakeholders have aligned on this roadmap. Please add any feedback or questions in: https://github.com/libp2p/test-plans/issues/58 ``` @@ -174,7 +174,7 @@ Depends on [C.1](#1-benchmarking-using-nix-builders) Relates to [Testground Milestone 4 (for large scale tests.)](https://github.com/testground/testground/blob/master/ROADMAP.md#4-provide-a-testground-as-a-service-cluster-used-by-libp2p--ipfs-teams) #### 2. AutoNat Depends on [testground/NAT and/or firewall support](https://github.com/testground/testground/issues/1299) -#### 3. Hole Punching +#### [3. Hole Punching](https://github.com/libp2p/test-plans/issues/21) Depends on [testground/NAT and/or firewall support](https://github.com/testground/testground/issues/1299) #### 4. AutoRelay #### 5. Custom topologies From 559856230f85b5ade08e0b5878ec3ed6d5316a60 Mon Sep 17 00:00:00 2001 From: Prithvi Shahi Date: Thu, 20 Oct 2022 17:18:29 -0700 Subject: [PATCH 13/15] remove extra word --- ROADMAP.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ROADMAP.md b/ROADMAP.md index 4946b1e93..9ad5151fc 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -3,7 +3,7 @@ ``` Date: 2022-10-20 Status: Accepted -Notes: Internal test-plans maintainers stakeholders have aligned on this roadmap. Please add any feedback or questions in: +Notes: Internal test-plans stakeholders have aligned on this roadmap. Please add any feedback or questions in: https://github.com/libp2p/test-plans/issues/58 ``` From c27f544d0f074739ccd21e327480b9f699386974 Mon Sep 17 00:00:00 2001 From: Prithvi Shahi Date: Thu, 20 Oct 2022 17:21:49 -0700 Subject: [PATCH 14/15] update to design doc --- DESIGN.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/DESIGN.md b/DESIGN.md index 0a2ff13cb..3c199c577 100644 --- a/DESIGN.md +++ b/DESIGN.md @@ -46,6 +46,8 @@ This document describes our process for testing interoperability & backward comp - Anything `js-libp2p` related requires the `ping` test to start - Benchmarking must relate to [Remote Runners][remote-runners] + - https://github.com/testground/testground/pull/1425 + - https://github.com/testground/testground/issues/1392 **Questions** From a62532e0ada7fefc7c4862ed6d029c5248148347 Mon Sep 17 00:00:00 2001 From: Prithvi Shahi Date: Thu, 20 Oct 2022 17:28:48 -0700 Subject: [PATCH 15/15] update readme --- README.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/README.md b/README.md index 362267b73..c73086f92 100644 --- a/README.md +++ b/README.md @@ -5,6 +5,13 @@ This repository contains Testground test plans for libp2p components. +## Roadmap + +Our roadmap for test-plans can be found here: https://github.com/libp2p/test-plans/blob/master/ROADMAP.md + +It represents current projects the test-plans maintainers are focused on and provides an estimation of completion targets. +It is complementary to those of [go-libp2p](https://github.com/libp2p/go-libp2p/blob/master/ROADMAP.md), [rust-libp2p](https://github.com/libp2p/rust-libp2p/blob/master/ROADMAP.md), [js-libp2p](https://github.com/libp2p/js-libp2p/blob/master/ROADMAP.md), and the [overarching libp2p project roadmap](https://github.com/libp2p/specs/blob/master/ROADMAP.md). + ## How to add a new version to ping/go When a new version of libp2p is released, we want to make it permanent in the `ping/go` test folder.