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: Bump libp2p-swarm dependents #3225

Merged
merged 4 commits into from
Dec 12, 2022
Merged

Conversation

mxinden
Copy link
Member

@mxinden mxinden commented Dec 10, 2022

Description

Follow-up to #3170 (comment)

Notes

Links to any relevant issues

Should as well "fix" the cargo semver check failures for libp2p-dcutr and libp2p-relay, see #2647 (comment).

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

CHANGELOG.md Show resolved Hide resolved
Co-authored-by: Elena Frank <elena.frank@protonmail.com>
CHANGELOG.md Show resolved Hide resolved
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.

I'd like us to start prioritizing, which changes are worth a breaking change. Removing deprecated APIs is IMO not worth it, the motivation should be bigger. We should obviously remove them eventually but it would be great if we can prioritize merging backwards-compatible changes and make more patch releases.

#3170 is already merged so I am happy to go ahead here but it is something to consider for the future.

@thomaseizinger
Copy link
Contributor

Should as well "fix" the cargo semver check failures for libp2p-dcutr and libp2p-relay, see #2647 (comment).

Only for the current release cycle though. Once it is released, it will come back unless we also merge #3213.

@mergify mergify bot merged commit 7c10942 into libp2p:master Dec 12, 2022
@mxinden
Copy link
Member Author

mxinden commented Dec 12, 2022

I'd like us to start prioritizing, which changes are worth a breaking change. Removing deprecated APIs is IMO not worth it, the motivation should be bigger. We should obviously remove them eventually but it would be great if we can prioritize merging backwards-compatible changes and make more patch releases.

That is a good point I did not consider before.

Thus far I was operating with the mindset of always-remove-deprecation-in-next-release. Given this more thought, there is no good reason to do so, i.e. removing deprecated methods is not worth a breaking change in itself.

#3170 is already merged so I am happy to go ahead here but it is something to consider for the future.

👍 please continue being vocal about this. I will try to do better in the upcoming releases.

@thomaseizinger
Copy link
Contributor

#3170 is already merged so I am happy to go ahead here but it is something to consider for the future.

👍 please continue being vocal about this. I will try to do better in the upcoming releases.

It only came to my mind on this PR actually! To make this planning manageable, I'd suggest we create milestones. We can add open PRs to that so we know what to merge for the next release. We might also want to think about a policy for how long we keep deprecated APIs around f.e. (1, 2, ... n releases?)

umgefahren pushed a commit to umgefahren/rust-libp2p that referenced this pull request Mar 8, 2024
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