tokio-rs
Call for breaking changes
This issue tracks the release of bytes v2.0.0. The semver hack will be used to allow Tokio to upgrade from v1 without a breaking change.
We intend to make the following changes as part of this release:
- [ ] https://github.com/tokio-rs/bytes/issues/479#issuecomment-2612371135
Before going through with this release, we need to consider whether there are any other breaking changes that we would like to make now that we have the opportunity. Note that we can only make breaking changes that are compatible with the semver hack. Therefore, I am announcing a call for breaking changes period until March 2nd 2025 for suggestions.
To suggest a breaking change:
- Open a new issue with your suggestion.
- Post a comment on this issue, referencing your new issue.
The issue must explain what exactly you are suggesting, and it must explain why your breaking change is possible to carry out when we are using the semver hack. If the change you are suggesting is an existing issue, add a comment to that issue with this information and post a comment here linking to your comment.
To avoid cluttering this issue, please use the sub-issues for discussion. Accepted suggestions will be added to the list at the top of this issue.
The semver hack will be used to allow Tokio to upgrade from v1 without a breaking change.
I'm not sure if tokio can depend on bytes 2.0 in practice. If someone updates tokio only without updating bytes it'll break until they also update bytes. However, tokio can keep bytes 1.x dependency indefinitely. It will look bit dumb having both 1.0 and 2.0 in the tree and it may trip some lazy duplication checking that doesn't take semver trick into account but avoids this problem.
Of course it may be reasonable to declare that this is not really a breaking change and it has trivial solution anyway, so I'm not saying it's definitely broken, just something to be aware of. A possible middle ground is to keep 1.0 for a while and raise it later but I'm not sure if it achieves anything interesting aside from giving people ability to upgrade bytes later (presumably if they cannot for some reason such as MSRV issues).
@Kixunil That's acceptable. It will not break existing code:
- If you have a
Cargo.lockthat used to work, you have a version of Tokio and Bytes that works together. - If you don't have a
Cargo.lock, then you will get the latest of both, so you get a version of Tokio and Bytes that works together.
Yes, it means that you can get breakage when you carry out an update. It doesn't break any existing configurations, and that's good enough to me.
Thumbs up for no default features.
Also, a bytes-core that only has trait definitions would solve this issue.
https://github.com/tokio-rs/bytes/issues/461
Also, a
bytes-corethat only has trait definitions would solve this issue.
This was discussed recently, it's not possible because the traits contain Bytes in their public API.
Reminder to not discuss suggestions on this issue. Instead, open a sub-issue and discuss there or on our discord, please.
This was discussed recently, it's not possible because the traits contain Bytes in their public API.
Instead, open a sub-issue and discuss there or on our discord, please.
Just a heads up, it is impossible for me (or anyone new to the party) to keep up with the discussion if it takes place in multiple places, specially if some of those discussions take place on platforms that gatekeep the discussion (aka Google won't index the discord chat, for instance)
With that said, im sorry I missed the reason why we cannot create a bytes-core crate. I'll take another look at the thumb arm issue. Maybe breaking down the trait into pieces could work.
I've added my own suggestion:BufMut::advance_mut should make cnt > self.remaining_mut() unsound #760
Just a heads up, it is impossible for me (or anyone new to the party) to keep up with the discussion if it takes place in multiple places
The issue where the discussion happened is literally the first linked issue here and you've already participated in that discussion, so GH should notify you unless you've unsubscribed. So you messed up big time but I accept your apology.
@Altair-Bueno Btw, as for https://github.com/tokio-rs/bytes/issues/461, it has already been explained in related PRs some times (e.g., see https://github.com/tokio-rs/bytes/pull/573#issuecomment-1271567631) that it can be addressed without requiring any breaking changes.
I've opened #786 for adding try_advance which I think would be a breaking change.
Adding feature of no_panic. There might be embedded applications that don't want to panic and bytes should be able to support that. Not sure if there is a good way to do that though.
@adityashah1212 it'd have to be the other way around: a feature named panicking_apis (I assume you're talking about writing past end?) but it'd be breaking here because it'd change the required trait methods. But I think if your code is correct you won't need it since the optimizer will remove the panicking code.
But I think if your code is correct you won't need it since the optimizer will remove the panicking code.
That sounds like C++ with extra steps.
We are doing things in Rust for a reason, doing this is the IT equivalent of diagnosing a disease by reading the bones.
Reminder to open new issues for suggestions. Individual suggestions should not be discussed here.