-
Notifications
You must be signed in to change notification settings - Fork 961
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.
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
chore: prepare libp2p v0.52.0 release #4053
Conversation
Missing removal of all |
How about introducing two sections. A TL;DR section documenting the gotchas, i.e. the things you need to know before upgrading and a longer section advertising the cool new features that this release brings with it? I feel like while our current changelogs show what changed, they don't tell the story of why someone should upgrade. |
I think changelogs should be just that, a log of changes. I see them as a point of reference. Advertising new features and releases should be done in blogposts or other marketing material. I do think that we should sort the changelogs by priority. Ideally, we'd also adopt the keep-a-changelog format. |
I did that for all crates that are included in the |
Removed the call-outs section. I would still like to highlight some subtle changes in the GitHub release page. @thomaseizinger anything missing here? If not, mind approving? |
Sure thing! I am still in favor of writing a blog post as well. I should be able to spend some cycles on that later today.
Don't think so. |
Our move to workspace dependencies seems to be problematic when releasing. Releasing
Releasing
Off the top of my head this is due to |
@thomaseizinger I am logging off soon. Will debug this more tomorrow. Let me know in case you have any ideas in the meantime. |
Yeah, cyclic dependencies are not good, even if dev-dependencies technically allow them. We should test |
I think an alternative fix to #4090 could be use path dependencies for all workspace dependencies for |
This seems to be the recommended way of dealing with this: rust-lang/futures-rs#2305. The original issue is here: rust-lang/cargo#4242 Reading that thread, it appeared to me that this means that our crate's test won't run in a crater run then because it is missing important dependencies. I think it would be good to only use |
All of the removed `dev-dependencies` are only for testing the upgrade procedure in `libp2p-core`. Ironically, this test does not use a single API of `multistream-select`. Thus, this test is simply misplaced in this crate. If we wanted to retain it, it should probably go into `libp2p` itself as that one already depends on all required crates. Related: #4053. Pull-Request: #4090. Co-Authored-By: Thomas Eizinger <thomas@eizinger.io>
We have two "interface" crates in our workspace: `libp2p-core` and `libp2p-swarm`. Most crates depend on both of these. To compile the tests for this crate, we often need a concrete implementation to some of these interfaces. When specifying a workspace-inherited dependency, we don't get to choose to omit the `version` field next to the path. If a dependency is `path`-only however, it will be tripped by `cargo` during the release process which is why all of this worked before our move to workspace inheritance. With this patch, we change the minimum amount of dependencies necessary back to `path` dependencies to allowing releasing of our crates. Related: #4053. Pull-Request: #4091. Co-Authored-By: Thomas Eizinger <thomas@eizinger.io>
Tagged and published the following crates:
|
Submitted to TWIR: rust-lang/this-week-in-rust#4446 |
With rust-libp2p v0.52.0 released (libp2p/rust-libp2p#4053) we can now run off of the official release commit hash.
Pull-Request: libp2p#4053. Co-Authored-By: Max Inden <mail@max-inden.de> Co-Authored-By: Thomas Eizinger <thomas@eizinger.io>
Description
Notes & open questions
Release milestone https://github.com/libp2p/rust-libp2p/milestone/6.
Change checklist