RFC: Rusoto priorities

[matthewkmayer]

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 .

Other

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. ❤️

[xrl]

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.

[srijs]

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

[matthewkmayer]

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