README.md in redis_failover-0.8.9 vs README.md in redis_failover-0.9.0

@@ -127,11 +127,21 @@
      :db            - db to use for redis nodes (optional)
      :namespace     - namespace for redis nodes (optional)
      :logger        - logger override (optional)
      :retry_failure - indicate if failures should be retried (default true)
      :max_retries   - max retries for a failure (default 3)
+     :safe_mode     - indicates if safe mode is used or not (default true)
+     :master_only   - indicates if only redis master is used (default false)
 
+The RedisFailover::Client also supports a custom callback that will be invoked whenever the list of redis clients changes. Example usage:
+
+    RedisFailover::Client.new(:zkservers => 'localhost:2181,localhost:2182,localhost:2183') do |client|
+      client.on_node_change do |master, slaves|
+        logger.info("Nodes changed! master: #{master}, slaves: #{slaves}")
+      end
+    end
+
 ## Manual Failover
 
 Manual failover can be initiated via RedisFailover::Client#manual_failover. This schedules a manual failover with the
 currently active Node Manager. Once the Node Manager receives the request, it will either failover to the specific
 server passed to #manual_failover, or it will pick a random slave to become the new master. Here's an example:
@@ -158,13 +168,15 @@
 
 - Note that currently multiple Node Managers are currently used for redundancy purposes only. The Node Managers do not communicate with each other to perform any type of election or voting to determine if they all agree on promoting a new master. Right now Node Managers that are not "active" just sit and wait until they can grab the lock to become the single decision-maker for which Redis servers are available or not. This means that a scenario could present itself where a Node Manager thinks the Redis master is available, however the actual RedisFailover::Client instances think they can't reach the Redis master (either due to network partitions or the Node Manager flapping due to machine failure, etc). We are exploring ways to improve this situation.
 
 ## Resources
 
+- Check out Steve Whittaker's [redis-failover-test](https://github.com/swhitt/redis-failover-test) project which shows how to test redis_failover in a non-trivial configuration using Vagrant/Chef.
 - To learn more about Redis master/slave replication, see the [Redis documentation](http://redis.io/topics/replication).
 - To learn more about ZooKeeper, see the official [ZooKeeper](http://zookeeper.apache.org/) site.
 - See the [Quick ZooKeeper Guide](https://github.com/ryanlecompte/redis_failover/wiki/Quick-ZooKeeper-Guide) for a quick guide to getting ZooKeeper up and running with redis_failover.
 - To learn more about how ZooKeeper handles network partitions, see [ZooKeeper Failure Scenarios](http://wiki.apache.org/hadoop/ZooKeeper/FailureScenarios)
+
 
 ## License
 
 Please see LICENSE for licensing details.