It is a major release that remains binary and source compatible with
2.2.x.
In summary we’ve got a replacement for Scala’s NonFatal,
a new Task.deferAction builder for defering tasks with an injected scheduler,
Task and Coeval run-loop optimizations, the Observable.observeOn
operation after popular request, a Consumer.transformInput for
transforming consumers by transforming their input stream,
fixes for the reactive streams integration and more.
See details below.
It is a minor release that’s binary and source compatible with
2.2.x, fixing a critical bug that happens in Scala 2.12, due to
changes to how flatMap is implemented in scala.concurrent.Future:
Bug #330:
Ack.Continue.transformWith and Ack.Stop.transformWith
are not stack-safe
Impact of this bug: it does NOT impact most (probably all)
functionality in Monix, because Monix rarely flatMaps direct
Continue references (due to batching and optimizations) and we have
had extensive tests for long loops that could trigger this problem.
However this bug can be dangerous for people that have implemented the
communication protocol (as
described in the docs)
by themselves. If you’re using Monix with Scala 2.12, then upgrade
immediately.
Upgrade should be safe, being binary compatible with all previous
2.2.x versions.
It is a minor release that’s binary and source compatible with 2.2.x.
In summary:
Implemented a circuit breaker for Task, for providing stability
and preventing cascading failures in distributed systems
Added Task!.memoizeOnSuccess and Coeval!.memoizeOnSuccess
operators that only caches the result (with idempotency guarantees)
for successful results, while re-evaluating the source on failures
Added Task.deferFutureAction that helps with wrapping
Future-enabled APIs without requiring ExecutionContext in the
function signature, since Task can inject it for you
Added SingleAssignmentCancelable.plusOne for helping with building
Consumer objects
Moved and redesigned exceptions in monix.execution
Task.sequence now has lazy behavior in evaluating the given
sequence (previously we were doing a foldLeft on that sequence,
which could have strict behavior, depending on the collection type)