New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Rusoto priorities #1098

matthewkmayer opened this Issue Aug 18, 2018 · 3 comments


None yet
3 participants

matthewkmayer commented Aug 18, 2018

This project could use some clear guidance on where we're going and the stages of the project. Here's my thoughts:

Focus on Rusoto 1.0.0

Per #318 we should have support for all AWS services before 1.0.0. There are other features we probably want to support as well, but all AWS services is something I think there's solid agreement on.

In addition to having code and crates in place to support those services, they should also work. This means bug fixes as well. Should we have all known bugs fixed before 1.0.0?

Rusoto post 1.0.0

Extra features such as:

  • resurrect the rusoto_helpers crate. This is to provide higher level abstractions to improve ergonomics. It may turn into a helper crate per AWS service so users only have to pay for what they need. This would cover items such as #1083 , #1016 , #783 , #757 .


Should we have a stance on Rusoto supporting Rust 2018 edition? Or: should we stick with the existing edition of Rust?

too long, didn't read

Anyone not in support of fixing bugs and supporting all AWS services before adding other features?

Feedback welcome: like Rust, this is a group effort. ❤️


This comment has been minimized.


xrl commented Aug 20, 2018

What are our priorities on futures? It'd be swell to use the futures definitions now in rust's core lib.

Then what about async/await and async macros? Some great stuff which could give some serious perf wins.

I'm spiking on it right now but that's mostly for my own curiosity. The API changes take a while for me to navigate.


This comment has been minimized.


srijs commented Aug 21, 2018

Outside of what bugfixes and features we want to ship with, it seems prudent to take inventory of all crates that are currently part of our public API (such as futures, tokio and hyper), and either wait for those libraries to hit 1.0 as well or consider removing them from the public API (not possible for futures and tokio unfortunately).


This comment has been minimized.


matthewkmayer commented Oct 11, 2018

Excellent point, I had not thought about ensuring our publicly accessible dependencies are at 1.0 as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment