Futures and tokio maintenance status


Currently tokio and futures are being quite maintenance only, which means we will never reach 0.2 in near future.

I’m aware @alexcrichton is very busy mainly on the core organization. If that’s true, should we elect some new admins to drive the development?

Things are:
futures crate should be moved to tokio organization, or maybe nursery.
The tokio organization should have some new admins, preferably public (displayed on GitHub profile).

I’m not going to suggest myself as a leader (I haven’t gained so much trust from the community), but anyway I’m looking forward to having a refactored interface to asynchronous IO.


What makes you think they’re “maintenance only”?

This seems to be jumping the gun a bit.

Alex isn’t the only person driving tokio dev.


I’ve been opening issues and PRs to futures lately and Carl and Alex have been very quick and helpful in reviewing (even if my PRs were mostly poorly explained, not so good ideas :stuck_out_tongue:). It is actively maintained and developed by great maintainers and community as far as I can see.

More contributors are always needed, there are bunch of 0.2 tagged issues that anyone can go ahead and take a shot at. Perhaps you could expand on why you feel like moving the crate around or giving more people write access would help?


Do you have technical issues you’d like to see solved? We’re always willing to accept PRs and help with design! Carl, Aaron, and I are all maintainers of futures-rs and Tokio right now, and it is not maintenance only. The futures-rs repository lives under my account currently because that’s where it started and we originally thought it may move to the nursery or rust-lang, in which case we wanted to avoid bouncing the repo around from me, to tokio-rs, then to rust-lang. We’re of course always thrilled to have active contributors and if anyone’s feeling up to the task to help with design/triage/maintenance please feel free to reach out to us!

We are very hesitant to release an 0.2 release. The futures crate is basically a “public dependency” if every single crate that uses it. Each major release of the futures crate is a split in the ecosystem that’s very difficult (if at all) to work across major versions. With that in mind we’re trying to be very careful about releasing new major versions, ideally having as few as possible.

We’ve got a lot of cleanup planned for the 0.2 release but currently we don’t have any huge technical improvements planned for 0.2. Every technical improvement we’ve thought of so far has been implemented in the 0.1 release series, such as the upcoming task module revamp. It is our intention to keep doing this until we’re comfortable that we’ve identified all issues requiring an 0.2 release, and then we may consider an 0.2 release. If you’ve got breakage in 0.2 you’re awaiting I’d recommend sending a PR to implement the API on the 0.1 release, perhaps with a different name if possible and we can consider merging!


I would like to see 0.2 turned into branch like next.

Currently there are PRs and issues left open for ages, like https://github.com/tokio-rs/tokio-core/pull/84. I’m also waiting for a proper design allowing graceful shutdown (which, IMO should prohibit the use of spawn() for non reactor related operations).

There’s no tracking issue for 0.2 either, so maybe it’s a good idea to create one and have a more progressing discussion.