-
-
Notifications
You must be signed in to change notification settings - Fork 639
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vavr Minor Release 0.10.0 #2335
Comments
Analysis of API changesVavr 0.10.0 will contain the following changes:
Full report:
Note: the backw'incompat changes to (Priority)Queue.dropUntil(Predicate) look like false-positives to me. |
We will introduce new functional interfaces for Future.run(). Before (cryptic): static <T> Future<T> join(CheckedConsumer<Predicate<Try<? extends T>>> computation) { ... } After (human readable): static <T> Future<T> run(Task<? extends T> task) { ... } where @FunctionalInterface
public interface Task<T> {
void run(Complete<? extends T> complete) throws Throwable; // maybe Exception instead?
}
@FunctionalInterface
public interface Complete<T> {
void with(Try<? extends T> value);
} Usage: Future.run(complete -> {
// do some heavy work here
if (getMood() == Mood.GOOD) {
complete.with(Try.success("😊"));
} else {
complete.with(Try.failure(new BadMoodException());
}
}); Note: The new Future.run() API is good for many cases we needed Promise before. E.g. when having nested Futures: interface Future<T> {
Future<T> fallbackTo(Future<? extends T> that) {
return run(executor(), complete ->
onComplete(res -> {
if (res.isSuccess()) {
complete.with(res);
} else {
that.onComplete(alt -> complete.with(alt.isSuccess() ? alt : res));
}
})
);
}
} There is still one use-case for Promise we did not solve with the new Future.run() API: Passing the complete function to the outside of the run() method scope. See #2086 |
Current backward compatibility status (to be fixed)I ran the unit tests of v0.9.3 with the upcoming v0.10.0 classes. It boils down to:
The all should compile fine again. These are the compile errors (work in progress):
Update✅ All unit tests of v0.9.3 run with v0.10.0 (!) |
SummaryThese are the crucial changes from v0.9.3 -> v0.10.0 regarding backward compatibility.
Full backward compatibility analysisCaution: it needs to be interpreted correctly!
|
Thank you very much, Daniel! |
Since I discovered your library 9 months ago my way of doing things completly changed. So thanks for your great job and thanks for this update. |
Thank you for the kind words @PHaroZ ! |
Progress:
TODO
in the codeCurrently I see the following challenge:
Starting with Release 0.9.0, the master diverged from our releases in the following way:
The latter hinders us from
In order to solve this knot, I will clean up master the way that v1.0 related, backward incompatible changes will be stashed and removed from master.
Further more I will merge all of the following commits from the master branch into the release branch that make it into the next minor release v0.10.0. This allows to go on with development of v0.10.1 or v0.11.0 until v1.0.0 is ready.
release branch (maintenance)
These are the current 0.9.0 to 0.9.3 commits (cherry-picked from master and edited to be backward compatible):
master branch (development)
I replayed the master history of 0.9.0 up to now (10.01.2019) and moved backward incompatible changes to the stash-pre-0.10.0 branch.
The text was updated successfully, but these errors were encountered: