Release 1.0.0-rc10

CHANGELOG.md

@@ -8,6 +8,14 @@ The `Unreleased` section name is replaced by the expected version of next releas
 
 ## [Unreleased]
 
+### Added
+### Changed
+### Removed
+### Fixed
+
+<a name="1.0.0-rc10"></a>
+## [1.0.0-rc10] - 2019-05-22
+
 ### Added
 
 - mechanism to remove logging regarding polling backoff [#32](https://github.com/jet/Jet.ConfluentKafka.FSharp/pull/32) HT [@szer](https://github.com/Szer) re [#31](https://github.com/jet/Jet.ConfluentKafka.FSharp/issues/31)
@@ -18,9 +26,6 @@ The `Unreleased` section name is replaced by the expected version of next releas
 - default auto-commit interval dropped from 10s to 5s (which is the `Confluent.Kafka` default) [#30](https://github.com/jet/Jet.ConfluentKafka.FSharp/pull/30)
 - removed curried `member` Method arguments in `Start` methods
 
-### Removed
-### Fixed
-
 <a name="1.0.0-rc9"></a>
 ## [1.0.0-rc9] - 2019-05-22
 
@@ -117,7 +122,8 @@ The `Unreleased` section name is replaced by the expected version of next releas
 
 (Stripped down repo for history purposes, see [`v0` branch](tree/v0) for implementation targeting `Confluent.Kafka` v `0.9.4`)
 
-[Unreleased]: https://github.com/jet/Jet.ConfluentKafka.FSharp/compare/1.0.0-rc9...HEAD
+[Unreleased]: https://github.com/jet/Jet.ConfluentKafka.FSharp/compare/1.0.0-rc10...HEAD
+[1.0.0-rc10]: https://github.com/jet/Jet.ConfluentKafka.FSharp/compare/1.0.0-rc8...1.0.0-rc10
 [1.0.0-rc9]: https://github.com/jet/Jet.ConfluentKafka.FSharp/compare/1.0.0-rc8...1.0.0-rc9
 [1.0.0-rc8]: https://github.com/jet/Jet.ConfluentKafka.FSharp/compare/1.0.0-rc7...1.0.0-rc8
 [1.0.0-rc7]: https://github.com/jet/Jet.ConfluentKafka.FSharp/compare/1.0.0-rc6...1.0.0-rc7

README.md

@@ -10,7 +10,7 @@ See [the Equinox QuickStart](https://github.com/jet/equinox#quickstart) for exam
 
 ## Components
 
-The components within this repository are delivered as (presently single) multi-targeted Nuget package targeting `net461` (F# 3.1+) and `netstandard2.0` (F# 4.5+) profiles
+The components within this repository are delivered as a multi-targeted Nuget package targeting `net461` (F# 3.1+) and `netstandard2.0` (F# 4.5+) profiles
 
 - [![NuGet](https://img.shields.io/nuget/vpre/Jet.ConfluentKafka.FSharp.svg)](https://www.nuget.org/packages/Jet.ConfluentKafka.FSharp/) `Jet.ConfluentKafka.FSharp`: Wraps `Confluent.Kafka` to provide efficient batched Kafka Producer and Consumer configurations, with basic logging instrumentation.
   [Depends](https://www.fuget.org/packages/Jet.ConfluentKafka.FSharp) on `Confluent.Kafka [1.0.0]`, `librdkafka [1.0.0]` (pinned to ensure we use a tested pairing enterprise wide), `Serilog` (but no specific Serilog sinks, i.e. you configure to emit to `NLog` etc) and `Newtonsoft.Json` (used internally to parse Broker-provided Statistics for logging purposes).
@@ -69,23 +69,25 @@ Equinox places some key constraints on all components and dependencies:-
 - aim to add any resilience features as patches to upstream repos
 - thorough test coverage; integration coverage for core wrapped functionality, unit tests for any non-trivial logic in the wrapper library 
 
-You can see [the development process history here](https://github.com/jet/equinox/pull/87). The base code is taken from Jet's Inventory Management System. (**NB the version of `Confluent.Kafka` used in production is presently `0.9.4`**)
+You can see [the development process history here](https://github.com/jet/equinox/pull/87). The base code originates from Jet's Inventory Management System (at the point it was taken, it worked against `Confluent.Kafka` v `0.11.4`**)
+
+In addition to being used in the [`dotnet new eqxprojector -k` template](https://github.com/jet/dotnet-templates/tree/master/equinox-projector), there are at least two Jet teams using it independent of that.
 
 ### What is Kafunk ?
 
 [Kafunk](https://github.com/jet/kafunk) is an F# implementation of a Kafka Client - it's presently unmaintained (and has only trickle of usage within the Jet org, chiefly due to the fact that it does not support newer protocol versions necessitated by our broker configurations).
 
-### What about `jet-confluent-kafka` and `Confluent.Kafka` v `0.9.4` support?
+### What about `jet-confluent-kafka` and `Confluent.Kafka` v `0.11.4` support?
 
-The [`v0` branch](tree/v0) continues to house the original code as previously borne by the `master` of this repo. It's not going anywhere, especially while we have a significant number of `Confluent.Kafka` v `0.9.x` based clients in use across our systems.
+The [`v0` branch](tree/v0) continues to house the original code as previously borne by the `master` of this repo. It's not going anywhere, especially while we have a significant number of `Confluent.Kafka` v `0.11.x` based clients in use across our systems.
 
 - It will continue to address the need to provide an easy migration from the Kafunk API
-- There are significant non-trivial changes in lifetime management in the `RdKafka` drivers accompanying `0.9.5` and `0.9.6` (with potential behavioral changes implied too). While upgrading may be achievable without API changes, it does bring into play a series of changes related to how the RdKafka driver closes connections (which can result in long days chasing `AccessViolationException` and friends)
-- **NB Experience of [the changes necessary to accommodate the sweeping changes that the `Confluent.Kafka` v `1.0.0` API brings when compared to the `0.9.x` codebase](https://github.com/jet/equinox/pull/87) suggests it's likely to be a significant undertaking to adjust the `v0` branch to target `Confluent.Kafka 1.0.0` without significant surface API changes; there is no current plan to introduce such changes**
+- There are significant non-trivial changes in lifetime management in the `RdKafka` drivers accompanying `0.11.5` and `0.11.6` (with potential behavioral changes implied too). While upgrading may be achievable without API changes, it does bring into play a series of changes related to how the `rdkafka` driver closes connections (which can result in long days chasing `AccessViolationException` and friends)
+- **NB Experience of [the changes necessary to accommodate the sweeping changes that the `Confluent.Kafka` v `1.0.0` API brings when compared to the `0.11.x` codebase](https://github.com/jet/equinox/pull/87) suggests it's likely to be a significant undertaking to adjust the `v0` branch to target `Confluent.Kafka` v `>= 1.0.0` without significant surface API changes; there is no current plan to introduce such changes**
 
 ### Whats's involved in migrating from `Jet.ConfluentKafka.fsharp 0.9.x` to `Jet.ConfluentKafka.FSharp 1.0.x` ?
 
 - the producer and consumer API wrappers provide different semantics to the `v0` branch. It's recommended to validate that they make sense for your use case
-- upgrading to a new version of `Confluent.Kafka` typically implies a knock on effect from an associated increment in the underlying `RdKafka` driver version (TODO - explain key behavior and perf changes between what  `1.0.0` implies vs `0.9.4`)
+- upgrading to a new version of `Confluent.Kafka` typically implies a knock on effect from an associated increment in the underlying `rdkafka` driver version (TODO - explain key behavior and perf changes between what  `1.0.0` implies vs `0.11.4`)
 - you'll need to wire the (`Serilog`-based) logging through to your log sink (it's easy to connect it to an NLog Target etc). (The `v0` branch exposes a logging scheme which requires more direct integration)
 - there's a transitive dependency on `Newtonsoft.Json` v `11.0.2` (which should generally not be a problem to accommodate in most codebases)