*: Prepare v0.40.0-rc.1 release

[mxinden]

I would like to cut a new release of:

• A release candidate of all sub-crates (libp2p-XXX)
• multistream-select
• A release candidate of the libp2p crate - v0.40.0-rc.1

The reasoning for cutting release candidates for now, instead of a full release, is the amount of changes since the last release (see changelogs), especially #2248.

Any objections?

[thomaseizinger]

If #2248 is the main concern, shouldn't libp2p-core also get a RC instead of a new minor version?

[mxinden]

If #2248 is the main concern, shouldn't libp2p-core also get a RC instead of a new minor version?

My reasoning above was under the assumption that pretty much no one depends on any of the libp2p-XXX crates directly, but always through the main libp2p crate. Now that assumption is inconsistent with the reason why we have those sub-crates in the first place.

If #2248 is the main concern, shouldn't libp2p-core also get a RC instead of a new minor version?

Yes. Though that would imply that all other libp2p-XXX crates would need to be released as release candidates as well, as they would depend on the libp2p-core release candidate.

I need to give this more thought. Especially as this will not be the last time we cut a release candidate. I am now leaning towards cutting a release candidate of all the crates first, even though that is a bit of manual work.

More input welcome @thomaseizinger!

[thomaseizinger]

If #2248 is the main concern, shouldn't libp2p-core also get a RC instead of a new minor version?

Yes. Though that would imply that all other libp2p-XXX crates would need to be released as release candidates as well, as they would depend on the libp2p-core release candidate.

I need to give this more thought. Especially as this will not be the last time we cut a release candidate. I am now leaning towards cutting a release candidate of all the crates first, even though that is a bit of manual work.

I didn't think of that but that is a good point. I agree that if we want to do RCs, then doing an RC for all crates is probably the way to go.

Is a RC very different from depending on a Git revision? Perhaps we can just create an RC tag and encourage people to test with this version rather than going for all the churn of cutting a lot of RC. Even with a RC, people would have to manually update.

[mxinden]

rather than going for all the churn of cutting a lot of RC.

With a couple of RegExs this wasn't actually that hard. I will test out the full release candidate process via a crates release of each of the libp2p-XXX crates this time. Let's see whether it is worth it.

[mxinden]

I tagged and published the following releases:

• libp2p-core-0.30.0-rc.1
• libp2p-deflate-0.30.0-rc.1
• libp2p-dns-0.30.0-rc.1
• libp2p-floodsub-0.31.0-rc.1
• libp2p-gossipsub-0.33.0-rc.1
• libp2p-identify-0.31.0-rc.1
• libp2p-kad-0.32.0-rc.1
• libp2p-mdns-0.32.0-rc.1
• libp2p-metrics-0.1.0-rc.1
• libp2p-mplex-0.30.0-rc.1
• libp2p-noise-0.33.0-rc.1
• libp2p-ping-0.31.0-rc.1
• libp2p-plaintext-0.30.0-rc.1
• libp2p-pnet-0.22.0-rc.1
• libp2p-relay-0.4.0-rc.1
• libp2p-rendezvous-0.1.0-rc.1
• libp2p-request-response-0.13.0-rc.1
• libp2p-swarm-0.31.0-rc.1
• libp2p-swarm-derive-0.25.0-rc.1
• libp2p-tcp-0.30.0-rc.1
• libp2p-uds-0.30.0-rc.1
• libp2p-wasm-ext-0.30.0-rc.1
• libp2p-websocket-0.31.0-rc.1
• libp2p-yamux-0.34.0-rc.1
• multistream-select-0.10.4
• v0.40.0-rc.1

Downstream testing with the libp2p v0.40.0-rc.1 release candidate would be much appreciated.

• @kpp do you have some time to do a burn-in on Substrate / Polkadot?
• @thomaseizinger can you test this release on the Comit network stack?
• @elenaf9 let me know if things run smoothly on the iotledger stack.
• @ec2 let us know if this release resolves your issues with libp2p-gossipsub on Forest.
• I don't think there is an additional round of testing needed for lighthouse, given that @AgeManning has already been testing core/: Concurrent connection attempts #2248 (comment).

[mxinden]

Also, given that this is a rather large release, I am happy to support with the upgrade process. Feel free to ping me on your upgrade pull request.

[kpp]

KademliaBucketInserts is not in the root of kad anymore.

[mxinden]

@kpp v0.40.0-rc.2 and libp2p-kad-0.32.0-rc.2 are tagged and published.

[kpp]

#2214 Should be somehow addressed in the https://docs.rs/libp2p/0.40.0-rc.2/libp2p/swarm/trait.NetworkBehaviour.html docs.

[mxinden]

#2214 Should be somehow addressed in the https://docs.rs/libp2p/0.40.0-rc.2/libp2p/swarm/trait.NetworkBehaviour.html docs.

Good point @kpp. Do you want to propose a patch?

[kpp]

Do you want to propose a patch?

Sorry, I am not sure what's the difference between event_process = false and true to write a doc about it.

There is no fn inject_connection_closed override for MultiHandler which is a pain when implementing NetworkBehaviour with type ProtocolsHandler = MultiHandler<...>. How do I upgrade it to a new version https://github.com/paritytech/substrate/blob/d1ec40b49847fdb6dae8f00ab7ab08cef7dd10fc/client/network/src/discovery.rs#L556 ?

[thomaseizinger]

Do you want to propose a patch?

Sorry, I am not sure what's the difference between event_process = false and true to write a doc about it.

The docs currently say that by default, we require NetworkBehaviour_EventProcess_. That default changed so really only the current section needs to be negated.

Sorry that I missed this as part of the PR. If none beats me to it, I'll send an update in the next couple of days!

[elenaf9]

Thank you for the release @mxinden! Our upgrade went well and everything is working as expected.

[mxinden]

I have cut another release candidate (tagged and published) mostly due to #2304.

Let me know in case you are seeing any oddities with rc.3. If not, I would promote the release candidate to a proper release in the next couple of days. (//CC @AgeManning)

[mxinden]

There is no fn inject_connection_closed override for MultiHandler which is a pain when implementing NetworkBehaviour with type ProtocolsHandler = MultiHandler<...>. How do I upgrade it to a new version https://github.com/paritytech/substrate/blob/d1ec40b49847fdb6dae8f00ab7ab08cef7dd10fc/client/network/src/discovery.rs#L556 ?

I am a bit confused. MultiHandler does not implement NetworkBehaviour in the first place and thus also doesn't implement inject_connection_closed @kpp.

[mxinden]

I just branched off of master with v0.40, where further release candidates or the final release will be cut off of.

With that, master will now track the next (upcoming) release line, v0.41.

[mxinden]

For the record v0.40.0 is tagged and published #2323.