Add stability warning to README & book (ref #117)

This commit is contained in:
Blaine Bublitz 2020-05-27 15:40:51 -07:00
parent 1069461873
commit 464f0c86bb
2 changed files with 17 additions and 2 deletions

View File

@ -32,6 +32,16 @@
* [Cargo package](https://crates.io/crates/async-graphql)
* Minimum supported Rust version: 1.42 or later
## Stability: Unstable & Experimental
__This project doesn't currently follow SemVer, and there can be breaking changes on any version numbers. We will begin following SemVer once the project reaches v2.0.0__
Even though this project is above v1.0.0, we are rapidly changing and improving the API. This has caused versioning problems that aren't easily resolved because the project became popular very quickly (it was only started in March 2020).
We currently plan to start following SemVer once we reach the v2.0.0 release, which will happen once the API starts to stabilize. Unfortunately, we don't currently have the timeline for this.
If things don't seem to be compiling after an upgrade, it is likely you'll need to dive into compiler errors to update some syntax that changed. Feel free to open an issue if something seems weird!
## Examples
If you are just getting started, we recommend checking out our examples at: https://github.com/async-graphql/examples

View File

@ -8,10 +8,15 @@ You can define a Schema in Rust and procedural macros will automatically generat
I like GraphQL and Rust. I've been using `Juniper`, which solves the problem of implementing a GraphQL server with Rust. But Juniper had several problems, the most important of which is that it didn't support async/await at the time. So I decided to make this library for myself.
## Progress
## Stability: Unstable & Experimental
As I write this document today (April 15, 2020), a month and a half after I started `Async-graphql` development, it has surpassed my goal of becoming a fully functional graphql server library.
__This project doesn't currently follow SemVer, and there can be breaking changes on any version numbers. We will begin following SemVer once the project reaches v2.0.0__
Even though this project is above v1.0.0, we are rapidly changing and improving the API. This has caused versioning problems that aren't easily resolved because the project became popular very quickly (it was only started in March 2020).
We currently plan to start following SemVer once we reach the v2.0.0 release, which will happen once the API starts to stabilize. Unfortunately, we don't currently have the timeline for this.
If things don't seem to be compiling after an upgrade, it is likely you'll need to dive into compiler errors to update some syntax that changed. Feel free to open an issue if something seems weird!
## Examples