corrected futures 1.0 and 3.0 to 0.1 and 0.3

scrapped_chapters/introduction.md

@@ -13,7 +13,7 @@ Actually, at one point, Rust provided green threads for handling `async` program
 
 `Futures` in Rust comes in several versions, and that can be a source of some confusion for new users.
 
-#### Futures 1.0
+#### Futures 0.1
 
 This was the first iteration on how zero cost async programming could be implemented in Rust. Rusts 1.0 `Futures` is used using `combinators`. This means that we used methods on the `Futures` object themselves to chain operations on them.
 
@@ -36,9 +36,9 @@ As you can see, these chains quickly become long and hard to work with. Callback
 
 There were other issues as well, but the lack of ergonomics was one of the major ones.
 
-#### Futures 2.0
+#### Futures 0.2
 
-#### Futures 3.0
+#### Futures 0.3
 
 This is the current iteration over `Futures` and the one we'll use in our examples. This iteration solved a lot of the problems with 1.0, especially concerning ergonimics.
 

src/0_background_information.md

@@ -545,8 +545,8 @@ case it's the well known Javascript event loop).
 Once one of the sub-tasks changes state to either `fulfilled` or `rejected` the
 task is scheduled to continue to the next step.
 
-Syntactically, Rusts Futures 1.0 was a lot like the promises example above and
-Rusts Futures 3.0 is a lot like async/await in our last example.
+Syntactically, Rusts Futures 0.1 was a lot like the promises example above and
+Rusts Futures 0.3 is a lot like async/await in our last example.
 
 Now this is also where the similarities with Rusts Futures stop. The reason we 
 go through all this is to get an introduction and get into the right mindset for

src/3_generators_async_await.md

@@ -38,7 +38,7 @@ coroutines which Rust uses today.
 
 ### Combinators
 
-`Futures 1.0` used combinators. If you've worked with `Promises` in JavaScript,
+`Futures 0.1` used combinators. If you've worked with `Promises` in JavaScript,
 you already know combinators. In Rust they look like this:
 
 ```rust,noplaypen,ignore
@@ -58,7 +58,7 @@ let rows: Result<Vec<SomeStruct>, SomeLibraryError> = block_on(future);
 2. Not optimal memory usage
 3. Did not allow to borrow across combinator steps.
 
-Point #3, is actually a major drawback with `Futures 1.0`.
+Point #3, is actually a major drawback with `Futures 0.1`.
 
 Not allowing borrows across suspension points ends up being very
 un-ergonomic and to accomplish some tasks it requires extra allocations or
@@ -80,7 +80,7 @@ async/await as keywords (it can even be done using a macro).
 4. Very memory efficient
 5. Allows us to borrow across suspension points
 
-The last point is in contrast to `Futures 1.0`. With async/await we can do this:
+The last point is in contrast to `Futures 0.1`. With async/await we can do this:
 
 ```rust, ignore
 async fn myfn() {
@@ -210,7 +210,7 @@ Now, there are some limitations in our naive state machine above. What happens w
 `borrow` across a `yield` point?
 
 We could forbid that, but **one of the major design goals for the async/await syntax has been
-to allow this**. These kinds of borrows were not possible using `Futures 1.0` so we can't let this
+to allow this**. These kinds of borrows were not possible using `Futures 0.1` so we can't let this
 limitation just slip and call it a day yet.
 
 Instead of discussing it in theory, let's look at some code.