Offering Help with libp2p Releases

[grumbach]

Hi libp2p team,

I’m from Autonomi—we’ve been actively using and contributing to libp2p, and we really appreciate all the great work and support from your team. It’s a core component of our stack, and we rely on several recent improvements that are already merged into master (#6015, #5971, ...).

However, the lack of a recent official release is currently blocking us from leveraging these in production. We’ve considered forking, but we’d much rather collaborate upstream to avoid fragmentation and contribute to the sustainability of the project.

Would the team be open to having one of our engineers help out with libp2p releases on a regular basis? We’re happy to coordinate on process, follow any required guidelines, and help reduce the burden on your side—especially if resourcing is the main bottleneck.

Let us know if this is something you’d be open to exploring. We’re eager to support libp2p not just as users, but also as contributors committed to its success.

Warm regards,

Anselme

[jxs]

Hi, and thanks for your contributions and this feedback!

However, the lack of a recent official release is currently blocking us from leveraging these in production. We’ve considered forking, but >we’d much rather collaborate upstream to avoid fragmentation and contribute to the sustainability of the project.

The slow release cadence isn’t due to a lack of manpower, but more due to lack of demand for more frequent releases, we take the opportunity to batch as many features and breaking changes as possible into each one. In the past, users have expressed concerns about too many frequent breaking changes, which led them to stick with older versions.

Whenever users ask us for releases we take that into consideration and try to do it faster, sometimes by releasing the inner dependency so that the users can use the features without us needing to bump the main libp2p.
From your end the only time you asked for a release was on #6022 (reply in thread) right? The async-std PR's have been merged and we were planning on releasing tomorrow.

Regarding forking, If I understand correctly, antnode is a binary crate right? In that case, how would forking the repository help, compared to just using libp2p as a git dependency? If by fork you are referring to #6022 (reply in thread) that suggestion by @dariusc93 was so that you kept using 0.55. Using a git dependency for libp2p would also work.
Forking isn't also a problem, we do it with lighthouse and gossipsub so that we are able to test features that we then assess if they are improvements and deserved to be upstreamed. One can fork and still submit contributions that greatly help the project move forward.

Would the team be open to having one of our engineers help out with libp2p releases on a regular basis? We’re happy to coordinate on >process, follow any required guidelines, and help reduce the burden on your side—especially if resourcing is the main bottleneck.

Can you elaborate on what you had in mind specifically?

Cheers!

[grumbach]

Hi @jxs, thanks for your answer!

The async-std PR's have been merged and we were planning on releasing tomorrow.

This is excellent news!

If I understand correctly, antnode is a binary crate right? In that case, how would forking the repository help, compared to just using libp2p as a git dependency?

We're using libp2p not only with our binaries but also throughout our library crates (autonomi, ant-node which also has a library in addition to the binary) this is why we prefer using released versions of libp2p (or a fork).

Can you elaborate on what you had in mind specifically?

Maintaining separate libp2p releases for each small addition is costly, so we’re exploring a simpler option—joining the project directly. We’d like to propose having someone from our team assist with releases to support a more frequent cycle.
Most of our changes are non-breaking and could be released more frequently as minor versions, this is where we would like to help.