Stage 0.3.0 release

[cramertj]

r? @taiki-e @seanmonstar @Nemo157

[yoshuawuyts]

Running a test now on async-std to check if anything is broken. Will update this comment to report back.

edit: yes everything seems to pass locally 🎉. Filed async-rs/async-std#460 to test the latest master on CI once too.

[cramertj]

@yoshuawuyts Thanks for helping review! <3

[yoshuawuyts]

async-rs/async-std#460 passed on CI, which means that as far as async-std is concerned this patch should be good to go!

@cramertj @taiki-e @Nemo157 thanks so much for the work you've put in to get this release out!

[taiki-e]

Could you replace all "=0.3.0" with "0.3.0"? (I think "=" requirements are no longer necessary.)

[taiki-e]

There is a problem trying to update in tokio.
commit: tokio-rs/tokio@fa71a58

error: implementation of `core::future::future::Future` is not general enough
   --> examples/connect.rs:31:5
    |
31  |       tokio::spawn(async move {
    |       ^^^^^^^^^^^^ implementation of `core::future::future::Future` is not general enough
    |
    = note: `futures_util::sink::send_all::SendAll<'0, tokio_util::codec::framed_write::FramedWrite<tokio::io::stdout::Stdout, codec::Bytes>, futures_util::stream::stream::map::Map<futures_util::stream::stream::filter_map::FilterMap<tokio_util::codec::framed_read::FramedRead<tokio::net::tcp::split::ReadHalf<'1>, codec::Bytes>, futures_util::future::ready::Ready<std::option::Option<std::vec::Vec<u8>>>, [closure@examples/connect.rs:99:25: 105:14]>, fn(std::vec::Vec<u8>) -> std::result::Result<std::vec::Vec<u8>, std::io::Error> {std::result::Result::<std::vec::Vec<u8>, std::io::Error>::Ok}>>` must implement `core::future::future::Future`, for any two lifetimes `'0` and `'1`...
    = note: ...but `core::future::future::Future` is actually implemented for the type `futures_util::sink::send_all::SendAll<'_, tokio_util::codec::framed_write::FramedWrite<tokio::io::stdout::Stdout, codec::Bytes>, futures_util::stream::stream::map::Map<futures_util::stream::stream::filter_map::FilterMap<tokio_util::codec::framed_read::FramedRead<tokio::net::tcp::split::ReadHalf<'_>, codec::Bytes>, futures_util::future::ready::Ready<std::option::Option<std::vec::Vec<u8>>>, [closure@examples/connect.rs:99:25: 105:14]>, fn(std::vec::Vec<u8>) -> std::result::Result<std::vec::Vec<u8>, std::io::Error> {std::result::Result::<std::vec::Vec<u8>, std::io::Error>::Ok}>>`

I will investigate later, but it may be #1946 (comment).

[taiki-e]

@cramertj I filed #1955 and confirmed that the above problem can be fixed once #1955 is merged.

[Nemo157]

+1 to removing the = requirements. It might pay to have another CI job/steps that verify the internal minimum versions are correct, but that seems like it might be complicated enough that it's not worth it (I believe that properly testing it would require a bunch of Cargo.toml rewriting to add and remove path dependencies as needed to test against the released versions, although maybe cargo package could be leveraged to do this somehow).

[cramertj]

I've landed #1955, rebased this change, and amended the versions to remove =. PTAL.

[LucioFranco]

@taiki-e thank you for checking! <3

I say lets ship! Thank you for all your hard work @cramertj and others!

[Nemo157]

CI failure is unrelated, the job itself is wrong and needs fixing (it has been wrong all along, but Cargo is now erroring out in this situation).

[seanmonstar]

Thanks for coordinating this Taylor!

[theduke]

Out of curiosity, why is the futures executor feature on by default?

Seems like that would make sense as opt-in. Or rather not a feature at all but just a separate crate.

[cramertj]

@theduke It is exposed as its own crate, futures-executor, which is reexported through the main facade crate. I have no strong opinion about whether or not it be enabled by default.

[theduke]

Yeah I saw that.

It only introduces one additional dependency ( num_cpus, only with the threadpools feature on) but it seems to me like there is no big reason to tie it to the main facade at all and just provide it as the separate crate. It's certainly nice to have a simple stand alone executor available, but it would probably be a rather nieche thing to use, eg in small tests.

[cramertj]

@theduke The primary value I see is convenience of having things like block_on available, which makes it possible to write small standalone tests and example code using only the futures crate.

[seanmonstar]

It does seem useful for futures to be able to provide a block_on function out-of-the-box, even if a user probably shouldn't use it in most cases. 🤷‍♂

[theduke]

I can see that, and looking at how little code it is (< 1k lines) I'm not terribly bothered anymore.

It would have been nice to avoid the extra dependency, but that's not so relevant with the current crate structure anyway.

[shepmaster]

As an arbitrary small datapoint, SNAFU compiles and tests pass against this branch.

[Matthias247]

@cramertj Thanks for coordinating this! And even more so for going through the backlog and closing all long-term outstanding issues!

@seanmonstar

It does seem useful for futures to be able to provide a block_on function out-of-the-box, even if a user probably shouldn't use it in most cases. 🤷‍♂

There was some discussion on including block_on as a minimal executor into std - since it's currently quite hard to use async without any other dependency (you can't even run things in play.rust-lang without boilerplate). I created rust-lang/rust#65875 to implement this - but I don't whether and when we will see it getting there.