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

chore: deprecate void crate #5676

Merged
merged 1 commit into from
Nov 14, 2024
Merged

chore: deprecate void crate #5676

merged 1 commit into from
Nov 14, 2024

Conversation

hanabi1224
Copy link
Contributor

@hanabi1224 hanabi1224 commented Nov 14, 2024 •
edited
Loading

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
jxs
jxs approved these changes Nov 14, 2024
View reviewed changes
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 •
edited
Loading

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 •
edited
Loading

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
chore: bump crate version and update changelogs for libp2p#5676
10235b0
@hanabi1224 hanabi1224 mentioned this pull request Nov 15, 2024
Merged
4 tasks
hanabi1224 added a commit to hanabi1224/rust-libp2p that referenced this pull request Nov 15, 2024
@hanabi1224
chore: bump crate version and update changelogs for libp2p#5676
489993b
mergify bot added a commit that referenced this pull request Nov 20, 2024
@hanabi1224 @jxs @mergify
chore: bump crate versions and update changelogs for #5676 (#5678)
0e9dcdd 
## 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>
jxs pushed a commit to jxs/rust-libp2p that referenced this pull request Jan 6, 2025
@hanabi1224 @jxs
chore: deprecate void crate (libp2p#5676)
5a8d0e9 
## 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.
-->

The `void` crate provides a `Void` type that is conceptually equivalent
to the [`never`
type(!)](https://doc.rust-lang.org/std/primitive.never.html). This PR
tries to remove `void` crate from the dependency tree by replacing
`void::Void` with
[`std::convert::Infallible`](https://doc.rust-lang.org/std/convert/enum.Infallible.html)
that will eventually become an alias of the `never` type(!)

> This enum has the same role as [the ! “never”
type](https://doc.rust-lang.org/std/primitive.never.html), which is
unstable in this version of Rust. When ! is stabilized, we plan to make
Infallible a type alias to it:

## 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
- [ ] A changelog entry has been made in the appropriate crates
jxs added a commit to jxs/rust-libp2p that referenced this pull request Jan 6, 2025
@hanabi1224 @jxs @mergify
chore: bump crate versions and update changelogs for libp2p#5676 (lib…
e8a475d 
…p2p#5678)

## 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 libp2p#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>
elenaf9 added a commit to elenaf9/rust-libp2p that referenced this pull request Jan 13, 2025
@elenaf9
fix: minor version bump packages affected by libp2p#5676
2a49799
elenaf9 added a commit to elenaf9/rust-libp2p that referenced this pull request Jan 13, 2025
@elenaf9
fix: minor version bump packages affected by libp2p#5676
b4ef835
@elenaf9 elenaf9 mentioned this pull request Jan 13, 2025
Merged
4 tasks
elenaf9 added a commit to elenaf9/rust-libp2p that referenced this pull request Jan 13, 2025
@elenaf9
fix: minor version bump packages affected by libp2p#5676
dbcfed3
mergify bot pushed a commit that referenced this pull request Jan 14, 2025
@elenaf9
fix: minor version bump packages affected by #5676
4449024 
By switching from `void::Void` to `std::convert::Infallible`, #5676 changed the output types of some `NetworkBehavior` implementations in different protocols.
This can cause a type mismatch for the user and therefore is a breaking change.

#5678 (follow-up PR that version-bumped the crates affected by #5676) only bumped the patch version of the affected crates.
The current PR now changes it to a minor version bump for all crates where types in a `NetworkBehavior` implementation were affected.

It also reverts the version bump and CHANGELOG entry in `libp2p-quic` that was added with #5678, because that crate was never touched by the original PR.

Pull-Request: #5811.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jxs jxs jxs approved these changes

Assignees
No one assigned
Labels
send-it
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@hanabi1224 @dariusc93 @jxs