add docs badge and changelog (#5)

CHANGELOG.md

@@ -0,0 +1,13 @@
+# Changelog
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+## [0.18.0] - 2019-06-10
+Initial release of zeebest 🥏
+
+[Unreleased]: https://github.com/xmclark/zeebest/compare/v1.18.0...HEAD
+[0.18.0]: https://github.com/xmclark/zeebest/releases/tag/v0.18.0

README.md

@@ -1,4 +1,4 @@
-# the zeebest client [![CircleCI](https://circleci.com/gh/xmclark/zeebest.svg?style=svg)](https://circleci.com/gh/xmclark/zeebest)
+# the zeebest client [![docs.rs](https://docs.rs/zeebest/badge.svg)](https://docs.rs/zeebest) [![CircleCI](https://circleci.com/gh/xmclark/zeebest.svg?style=svg)](https://circleci.com/gh/xmclark/zeebest)
 
 This is an unofficial Rust client for [zeebe][zeebe]. Zeebe is a cool workflow orchestrator for microservices. 
 Get started by by spinning up a zeebe broker locally and deploy a workflow with: 
@@ -9,8 +9,33 @@ Get started by by spinning up a zeebe broker locally and deploy a workflow with:
 
 This crate offers a single `Client` type that comes with a plethora of methods for interacting with the zeebe gateway.
 
-Most methods are standard zeebe operations. The `worker` method is a bit more intersting that the other. It exposes a nice way
-to run a job handler for activated jobs.
+Most methods are standard zeebe operations. The `worker` method is a bit more interesting that the other. 
+
+Workers may activate and process jobs with a handler. A worker has a max number of concurrent jobs. The worker will do 
+its best to only request jobs from the broker up to the maximum amount. Each job handler may complete or fail a job.
+
+Workers currently will only poll the gateway manually, so you will need to use another system to process jobs periodically. 
+`tokio::Interval` does a pretty good job of this.
+
+```rust
+let client = Client::new("127.0.0.1", 26500).unwrap();
+
+let handler = move |activated_job| { 
+    Ok(JobResult::Complete { variables: None })
+};
+
+let mut worker = client.worker(
+    "rusty-worker",
+    "payment-service",
+    10000, // timeout
+    2, // max number of concurrent jobs
+    PanicOption::FailJobOnPanic,
+    handler,
+);
+
+// returns a stream of job results
+let job_stream = worker.activate_and_process_job();
+```
 
 ## Futures
 
@@ -28,44 +53,15 @@ This crate **does not support** the new async syntax. When the async stuff finds
 interested in upgrading the futures from 0.1 to 0.3 and supporting the async syntax. It will definitely help with readability. 
 
 Watch https://areweasyncyet.rs/ for updates.
-
-## Workers
-
-Workers may activate and process jobs with a handler. A worker has a max number of concurrent jobs. The worker will do 
-its best to only request jobs from the broker up to the maximum amount. Each job handler may complete or fail a job.
-
-Workers currently will only poll the gateway manually, so you will need to use another system to process jobs periodically. 
-`tokio::Interval` does a pretty good job of this.
 
 ## Zeebe Versions
 
-This crate will try to release with new releases of [zeebe][zeebe]. This client is tied to the gateway protobuf file. The
-protobuf file is copied from the main zeebe repo, and the protc compiler to executed on the file to generate the rust 
-bindings at build-time. When zeebe stabilizes to 1.0.0 this may matter less. In the mean time, use the version of `zeebest`
-that matches the minor patch version of your zeebe version e.g. 0.18.x. 
+This crate will attempt to release with [zeebe][zeebe]. This library is coupled to zeebe via the gateway protobuf file. 
+This service contract will likely only change between minor patches and I believe this crate will be easiest to use
+if the minor version of this crate matches zeebe. 
 
-## Todos
-
-There are some big issues that needed to be addressed! Some are in-flight, and there is already plenty of refactoring 
-to be done. My futures-foo is not fantastic.
-
-- [x] TESTS (I would like help mocking the grpc stuff, and with the futures testing)
-- [x] Get topology
-- [x] List workflows
-- [x] Deploy workflows
-- [x] Activate and complete job
-- [x] Publish message
-- [x] Create task workers API
-  - [x] Bounded number of concurrent tasks
-  - [x] Support stop workflow on panic
-- [x] Support any zeebe server (not just local)
-- [x] Create examples
-- [x] Futurize
-- [ ] Explore making the API more ergonomic for synchronous use cases (no futures)
-- [ ] Optimize the worker for readability and performance
-- [ ] Find good approach for ergonomic, high level worker runtime that does not involve knowledge of futures or `tokio`
-- [ ] Parse BPMN documents (another crate?)
-- [ ] Support grpc tls (needs to be implemented upstream first)
+When zeebe stabilizes to 1.0.0 this may matter less. In the mean time, use the version of `zeebest`
+that matches the minor patch version of your zeebe version e.g. 0.18.x. 
 
 ## Deving