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.

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: deprecate void crate #5676

Merged
merged 1 commit into from
Nov 14, 2024
Merged

Conversation

hanabi1224
Copy link
Contributor

@hanabi1224 hanabi1224 commented Nov 14, 2024

Description

The void crate provides a Void type that is conceptually equivalent to the never type(!). This PR tries to remove void crate from the dependency tree by replacing void::Void with std::convert::Infallible that will eventually become an alias of the never type(!)

This enum has the same role as the ! “never” type, which is unstable in this version of Rust. When ! is stabilized, we plan to make Infallible a type alias to it:

Notes & open questions

Change checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • A changelog entry has been made in the appropriate crates

@hanabi1224 hanabi1224 marked this pull request as ready for review November 14, 2024 13:57
Copy link
Member

@jxs jxs left a comment

Choose a reason for hiding this comment

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

Hi, and thanks for this! ❤️

@jxs jxs added the send-it label Nov 14, 2024
@mergify mergify bot merged commit 0c34d9f into libp2p:master Nov 14, 2024
71 of 72 checks passed
@dariusc93
Copy link
Member

dariusc93 commented Nov 14, 2024

Might want to update the Cargo.toml to bump the versions on them :)

EDIT: And changelogs

@dariusc93
Copy link
Member

CC @hanabi1224 @jxs

@hanabi1224 hanabi1224 deleted the deprecate-void branch November 14, 2024 23:32
@jxs
Copy link
Member

jxs commented Nov 15, 2024

Thanks for the reminding Darius, and I am sorry I didn't state explicitly why I moved ahead without asking for it.
I think in this case it's mostly redundant since it's only a dependency that we stop using, wdyt?

Edit:
you are aright Darius, I missed that the Cargo.toml was not updated, and we probably should add entries on CHANGELOG.md for every PR that touches the code

hanabi1224 added a commit to hanabi1224/rust-libp2p that referenced this pull request Nov 15, 2024
hanabi1224 added a commit to hanabi1224/rust-libp2p that referenced this pull request Nov 15, 2024
mergify bot added a commit that referenced this pull request Nov 20, 2024
## Description

<!--
Please write a summary of your changes and why you made them.
This section will appear as the commit message after merging.
Please craft it accordingly.
For a quick primer on good commit messages, check out this blog post:
https://cbea.ms/git-commit/

Please include any relevant issues in here, for example:

Related https://github.com/libp2p/rust-libp2p/issues/ABCD.
Fixes https://github.com/libp2p/rust-libp2p/issues/XYZ.
-->

This PR bumps crate versions and add changelog entries for crates that
are changed in #5676

Question: When should a crate version bump in the current release
process? Should it be right before or right after publishing? I see most
of current crate versions are published while some are not (e.g.
libp2p-autonat@0.13.1 libp2p-gossisub@0.48.0 and libp2p-perf@0.4.0 etc.)

## Notes & open questions

<!--
Any notes, remarks or open questions you have to make about the PR which
don't need to go into the final commit message.
-->

## Change checklist

<!-- Please add a Changelog entry in the appropriate crates and bump the
crate versions if needed. See
<https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md#development-between-releases>-->

- [x] I have performed a self-review of my own code
- [ ] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my
feature works
- [x] A changelog entry has been made in the appropriate crates

---------

Co-authored-by: João Oliveira <hello@jxs.pt>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants