Call for breaking changes

[Darksonn]

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:

• Make alloc optional (embedded rust) #479 (comment)

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:

1. Open a new issue with your suggestion.
2. 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.

[geeklint]

Suggestion: don't enable any feature flags by default in v2
#759

[Kixunil]

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).

[Darksonn]

@Kixunil That's acceptable. It will not break existing code:

• If you have a Cargo.lock that 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.

[Darksonn]

Reminder to not discuss suggestions on this issue. Instead, open a sub-issue and discuss there or on our discord, please.

[Altair-Bueno]

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.

[paolobarbolini]

I've added my own suggestion:BufMut::advance_mut should make cnt > self.remaining_mut() unsound #760

[dowlingw]

Suggestion: Remove DerefMut implementation on BytesMut
#757

[taiki-e]

@Altair-Bueno Btw, as for #461, it has already been explained in related PRs some times (e.g., see #573 (comment)) that it can be addressed without requiring any breaking changes.