Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

*: Prepare v0.40.0-rc.1 release #2290

Merged
merged 2 commits into from Oct 15, 2021
Merged

*: Prepare v0.40.0-rc.1 release #2290

merged 2 commits into from Oct 15, 2021

Conversation

mxinden
Copy link
Member

@mxinden mxinden commented Oct 14, 2021 •
edited

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
thomaseizinger reviewed Oct 14, 2021
View reviewed changes
Copy link
Contributor

@thomaseizinger thomaseizinger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@mxinden
Copy link
Member Author

mxinden commented Oct 14, 2021

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
Copy link
Contributor

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
Copy link
Member Author

mxinden commented Oct 15, 2021

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 mxinden merged commit a905665 into libp2p:master Oct 15, 2021
@mxinden
Copy link
Member Author

mxinden commented Oct 15, 2021

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.

@mxinden mxinden mentioned this pull request Oct 15, 2021
Closed
@mxinden
Copy link
Member Author

mxinden commented Oct 15, 2021

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
Copy link
Contributor

kpp commented Oct 15, 2021

KademliaBucketInserts is not in the root of kad anymore.

@mxinden mxinden mentioned this pull request Oct 15, 2021
Merged
@mxinden
Copy link
Member Author

mxinden commented Oct 15, 2021

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

@kpp
Copy link
Contributor

kpp commented Oct 15, 2021

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

@mxinden
Copy link
Member Author

mxinden commented Oct 18, 2021

#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
Copy link
Contributor

kpp commented Oct 18, 2021 •
edited

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
Copy link
Contributor

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
Copy link
Contributor

elenaf9 commented Oct 20, 2021

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

@mxinden mxinden mentioned this pull request Oct 20, 2021
Merged
@elenaf9 elenaf9 mentioned this pull request Oct 22, 2021
Merged
@mxinden
Copy link
Member Author

mxinden commented Oct 27, 2021

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 added a commit to mxinden/rust-libp2p that referenced this pull request Oct 29, 2021
@mxinden
swarm/src/behaviour: Fix outdated comment on derive's out_event
d9a76e7 
The default behaviour changed with
libp2p#2214. This updates the doc
comment.

Initially raised in
libp2p#2290 (comment).
@mxinden mxinden mentioned this pull request Oct 29, 2021
Merged
@mxinden
Copy link
Member Author

mxinden commented Oct 29, 2021

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 added a commit that referenced this pull request Oct 30, 2021
@mxinden
swarm/src/behaviour: Fix outdated comment on derive's out_event (#2318)
997cc9a 
The default behaviour changed with
#2214. This updates the doc
comment.

Initially raised in
#2290 (comment).
@mxinden
Copy link
Member Author

mxinden commented Oct 30, 2021

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
Copy link
Member Author

mxinden commented Nov 1, 2021

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

santos227 pushed a commit to santos227/rustlib that referenced this pull request Jun 20, 2022
@mxinden
swarm/src/behaviour: Fix outdated comment on derive's out_event (#2318)
5d8e245 
The default behaviour changed with
libp2p/rust-libp2p#2214. This updates the doc
comment.

Initially raised in
libp2p/rust-libp2p#2290 (comment).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@thomaseizinger thomaseizinger thomaseizinger left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@mxinden @thomaseizinger @kpp @elenaf9