| commit | f8d4e033e6427dbfad5b5c298fd7682f4e0637a8 | [log] [tgz] |
|---|---|---|
| author | Sean Griffin <sean@seantheprogrammer.com> | Tue Sep 18 12:07:59 2018 -0600 |
| committer | Sean Griffin <sean@seantheprogrammer.com> | Tue Sep 18 12:07:59 2018 -0600 |
| tree | 93579c82cc95c8b3e9c7ae8b726b8c02482085ee | |
| parent | 5887a1f300e011c7973faa93d6c9417b06cf9d22 [diff] |
Update our issue policy to make the issue tracker more manageable As per the discussions we've been having in gitter, this is a change that is meant to make the issue tracker more manageable, and more useful at surfacing features we should work on next. The goal is to have every open issue be something immediately actionable, meaning it is either a bug, or a feature we are actively planning to work on in the near future. Doing this effectively turns the issue tracker into a todo list, where any open issue is something we can actually work on today. It also gives better visibility into our roadmap, so folks can see what is coming in upcoming versions, vs things that sound reasonable for some point in the future. The other problem with using the issue tracker for feature requests is how binary open/closed is. We have to immediately decide whether a feature is reasonable for some point in the future, even before discussion around it happens. If we close the issue, that likely kills any discussion, but leaving it open implies that it's a feature we'd accept a PR for. Feature requests are something we still want to accept, but we will only accept them on our discourse going forward. This moves the discussion to a platform more designed for those sort of open ended discussions. It also effectively creates an informal RFC process, where asking someone to open an issue with their feature requests is effectively an accepted RFC, while leaving a thread open without explicitly rejecting the feature is effectively a postponed RFC. After this is merged I will go through all open issues and enforce this policy.
API Documentation: latest release – master branch
Diesel gets rid of the boilerplate for database interaction and eliminates runtime errors without sacrificing performance. It takes full advantage of Rust's type system to create a low overhead query builder that “feels like Rust.”
Find our extensive Getting Started tutorial at https://diesel.rs/guides/getting-started. Guides on more specific features are coming soon.
If you run into problems, Diesel has a very active Gitter room. You can come ask for help at gitter.im/diesel-rs/diesel. For help with longer questions and discussion about the future of Diesel, visit our discourse forum.
Anyone who interacts with Diesel in any space, including but not limited to this GitHub repository, must follow our code of conduct.
Licensed under either of these:
Unless you explicitly state otherwise, any contribution you intentionally submit for inclusion in the work, as defined in the Apache-2.0 license, shall be dual-licensed as above, without any additional terms or conditions.