Tracking issue for smol v2.0.0

[notgull]

Recently, it has been proposed to make a breaking change in the async-io crate to use I/O safe abstractions rather than AsRawFd (smol-rs/async-io#136). This would be a very large breaking change, since async-io is also re-exported in smol. Therefore, a breaking change in async-io would lead to use releasing smol v2.0.0. This issue aims to discuss if this should be done, how this should be done, and the potential impacts of this being done.

Discussion Questions

1). Should this happen?

First off, we should ask if this should even happen in the first place. It would be best for ecosystem cohesion to avoid a breaking change, after all. It was suggested that we could just add another constructor to Async that takes an AsFd type. However, it's been three years since smol v1.0.0 was released, and there are other breaking changes that could be made (see below). So the question is: are these breaking changes worth the major version bump?

2). What should happen?

Proposed examples of breaking changes, feel free to add any that I missed:

• async-fs
  • Seal extension traits (Seal DirBuilderExt, DirEntryExt, and OpenOptionsExt async-fs#10)
• async-lock
  • Add a default std feature for no_std usage
• async-io
  • Use AsFd instead of AsRawFd in the public API (Support creating an Async with AsFd rather than AsRawFd async-io#136)
• `futures-lite
  • Re-export some types from std in the public API (Drop future::{ready,pending} at the next bigger release futures-lite#35)

3). Who would be impacted?

async-std re-exports some of our crates in their public API, so this would affect them. cc @joshtriplett and @yoshuawuyts: are you find with this?

[taiki-e]

(polling is not used in the other smol-rs crates' public API, so it is not always necessarily tracked here.)

[notgull]

Good catch; I've removed polling from this list, although it probably needs a breaking change

[notgull]

@taiki-e What is the status of rust-lang/futures-rs#2207? Since futures-core and futures-io are public dependencies of smol I'd like to synchronize their releases if it'll come out in the near-ish future. But if they've one or two years out I think we should just release smol v2 now and release smol v3 once futures updates.

[taiki-e]

It is blocked on the Stream trait in the standard library. We will probably have to wait a few years.

[notgull]

I am in the process of publishing releases for the smol subcrates. Involved PRs:

• v2.0.0 futures-lite#78
• v3.0.0 async-lock#59
• v2.0.0 async-io#155
• v2.0.0 async-channel#69
• v2.0.0 async-fs#25

Once all of these are published we should be good-to-go to release smol v2.0.

cc dbus2/zbus#479

@smol-rs/admins Last real chance to make any breaking changes. Thoughts on this?

[eNV25]

When you start a new project with smol v1 right now it pulls in both async-io v1 and v2:

~/% mkdir smol-test
~/% cd smol-test
~/smol-test/% cargo init
     Created binary (application) package
~/smol-test/% cargo add smol
    Updating crates.io index
      Adding smol v1.3.0 to dependencies.
    Updating crates.io index
~/smol-test/% rg ' "(.*) (.*)",' -r '$1 v$2' Cargo.lock | sort -u
async-io v1.13.0
async-io v2.1.0
bitflags v1.3.2
bitflags v2.4.1
event-listener v2.5.3
event-listener v3.0.1
fastrand v1.9.0
fastrand v2.0.1
linux-raw-sys v0.3.8
linux-raw-sys v0.4.10
polling v2.8.0
polling v3.3.0
rustix v0.37.27
rustix v0.38.21

[taiki-e]

Maybe because async-signal raised the major version of async-io with a patch version (smol-rs/async-signal#26). Does downgrading async-signal cause the same problem?

[eNV25]

async-signal@=0.2.4 seems to work.

~/smol-test/% cargo add 'async-signal@=0.2.4'
    Updating crates.io index
      Adding async-signal =0.2.4 to dependencies.
    Updating crates.io index
~/smol-test/%
bitflags v1.3.2
bitflags v2.4.1
event-listener v2.5.3
event-listener v3.0.1
fastrand v1.9.0
fastrand v2.0.1
linux-raw-sys v0.3.8
linux-raw-sys v0.4.10
rustix v0.37.27
rustix v0.38.21

[notgull]

Smol v2 is now out