README.md in faraday-retry-1.0.3 vs README.md in faraday-retry-2.0.0

@@ -94,15 +94,18 @@
 retry_options = {
   retry_statuses: [401, 409]
 }
 ```
 
-#### Automatically handle the `Retry-After` header
+#### Automatically handle the `Retry-After` and `RateLimit-Reset` headers
 
-Some APIs, like the [Slack API](https://api.slack.com/docs/rate-limits), will inform you when you reach their API limits by replying with a response status code of `429` and a response header of `Retry-After` containing a time in seconds. You should then only retry querying after the amount of time provided by the `Retry-After` header, otherwise you won't get a response.
+Some APIs, like the [Slack API](https://api.slack.com/docs/rate-limits), will inform you when you reach their API limits by replying with a response status code of `429`
+and a response header of `Retry-After` containing a time in seconds. You should then only retry querying after the amount of time provided by the `Retry-After` header,
+otherwise you won't get a response. Other APIs communicate their rate limits via the [RateLimit-xxx](https://tools.ietf.org/id/draft-polli-ratelimit-headers-00.html#rfc.section.3.3) headers
+where `RateLimit-Reset` behaves similarly to the `Retry-After`.
 
-You can automatically handle this and have Faraday pause and retry for the right amount of time by including the `429` status code in the retry statuses list:
+You can automatically handle both headers and have Faraday pause and retry for the right amount of time by including the `429` status code in the retry statuses list:
 
 ```ruby
 retry_options = {
   retry_statuses: [429]
 }
@@ -125,19 +128,23 @@
 }
 ```
 
 ### Call a block on every retry
 
-You can specify a block through the `retry_block` option that will be called before every retry.
-There are many different applications for this feature, spacing from instrumentation to monitoring.
-Request environment, middleware options, current number of retries and the exception is passed to the block as parameters.
+You can specify a proc object through the `retry_block` option that will be called before every
+retry, before  There are many different applications for this feature, spacing from instrumentation to monitoring.
+
+
+The block is passed keyword arguments with contextual information: Request environment, middleware options, current number of retries, exception, and amount of time we will wait before retrying. (retry_block is called before the wait time happens)
+
+
 For example, you might want to keep track of the response statuses:
 
 ```ruby
 response_statuses = []
 retry_options = {
-  retry_block: -> (env, options, retries, exc) { response_statuses << env.status }
+  retry_block: -> (env:, options:, retries_remaining:, exception:, will_retry_in:) { response_statuses << env.status }
 }
 ```
 
 ## Development
 
@@ -145,11 +152,12 @@
 
 Then, run `bin/test` to run the tests.
 
 To install this gem onto your local machine, run `rake build`.
 
-To release a new version, make a commit with a message such as "Bumped to 0.0.2" and then run `rake release`.
-See how it works [here](https://bundler.io/guides/creating_gem.html#releasing-the-gem).
+### Releasing a new version
+
+To release a new version, make a commit with a message such as "Bumped to 0.0.2", and change the _Unreleased_ heading in `CHANGELOG.md` to a heading like "0.0.2 (2022-01-01)", and then use GitHub Releases to author a release. A GitHub Actions workflow then publishes a new gem to [RubyGems.org](https://rubygems.org/gems/faraday-retry).
 
 ## Contributing
 
 Bug reports and pull requests are welcome on [GitHub](https://github.com/lostisland/faraday-retry).