release 3.0.0 (#96)

Author: arbll

CHANGELOG.md

@@ -1,5 +1,21 @@
 ## Changes
 
+# 3.0.0 / 2019-10-18
+
+### Notes
+
+* [FEATURE] Add a way to configure the maximum size of a single payload (was always 1432, the optimal size for local UDP). See [#91][].
+* [IMPROVEMENT] Various performance improvements. See [#91][].
+* [OTHER] The client now pre-allocates 4MB of memory to queue up metrics. This can be controlled using the [WithBufferPoolSize](https://godoc.org/github.com/DataDog/datadog-go/statsd#WithBufferPoolSize) option.
+
+### Breaking changes
+
+- Sending a metric over UDS won't return an error if we fail to forward the datagram to the agent. We took this decision for two main reasons:
+  - This made the UDS client blocking by default which is not desirable
+  - This design was flawed if you used a buffer as only the call that actually sent the buffer would return an error
+- The `Buffered` option has been removed as the client can only be buffered. If for some reason you need to have only one dogstatsd message per payload you can still use the `WithMaxMessagesPerPayload` option set to 1.
+- The `AsyncUDS` option has been removed as the networking layer is now running in a separate Goroutine.
+
 # 2.3.0 / 2019-10-15
 
 ### Notes

README.md

@@ -65,18 +65,6 @@ Details about the advantages of using UDS over UDP are available in our [docs](h
 
 You can use this protocol by giving a `unix:///path/to/dsd.socket` address argument to the `New` constructor.
 
-
-### Blocking vs Asynchronous behavior
-
-When transporting DogStatsD datagram over UDS, two modes are available, "blocking" and "asynchronous".
-
-"blocking" allows for error checking but does not guarantee that calls to the library will return immediately. For example `client.Gauge(...)` might take an arbitrary amount of time to complete depending on server performance and load. If used in a hot path of your application, this behavior might significantly impact its performance.
-
-"asynchronous" does not allow for error checking but guarantees that calls are instantaneous (<1ms). This is similar to UDP behavior.
-
-Currently, in 2.x, "blocking" is the default behavior to ensure backward compatibility. To use the "asynchronous" behavior, use the `statsd.WithAsyncUDS()` option.
-We recommend enabling the "asynchronous" mode.
-
 ## Performance / Metric drops
 
 ### Tweaking kernel options