It has been a while since the last update on the overall direction and release planning of Akka, so before this year ends we thought it a good time to lay out the plans for the first half of the next. You have all seen the first milestone release of Akka Streams & HTTP and many of you tried it out and gave feedback—thanks a lot for that and keep it coming! The next step will be another milestone for these projects, focusing mostly on documentation. This will allow those of you who prefer reading text instead of the source code to also dive into the new and exciting features that are coming up, and if all goes well this will be available before Christmas so that you have something to play with during the vacation days :-) We will then spend the first quarter of 2015 polishing and optimizing Streams & HTTP—especially in response to all your valuable feedback!—and plan on releasing a 1.0 version against Akka 2.3.x in March.
We have also begun working on the first milestone towards the 2.4.0 release by removing the deprecated Akka Persistence APIs and cleaning up the internals. Previously we had planned to make 2.4 a long-term support version, the last version that works on Java 6 runtimes. This notion proved too limiting, since we would have needed to finish all the cleanup and finalize all experimental modules, a process that would have taken us at least into the second half of 2015. On the other hand we want to release a major update that fully incorporates Streams & HTTP as soon as possible. This is why we changed plans:
Untying this package means that instead of a large jump—previously we imagined Akka 3 with typed ActorRefs to be the next major version—we make more incremental steps. We will even try to keep 2.4 as compatible to 2.3 as we can make it; the ideal would be binary and source compatibility for the non-experimental modules, but we cannot make promises about this right now.
This has consequences on when to update our Java version dependency: without the dedicated big jump, there is no reason to hold back the update any longer than necessary. As our surveys have indicated great eagerness to update to Java 8, we will switch to that runtime version (and classfile format) with Akka 2.4-M1. The main reason for doing so is that we want to make use of the new features of the JDK as well as the JVM, most notably asynchronous file IO, CompletionStage (for our Java APIs) and better concurrency instruction intrinsics (in sun.misc.Unsafe). Seeing that many other open-source projects have made that switch already we feel that our users deserve the improved performance offered by this change. For those of you who use Akka on JRE6 in production and who cannot upgrade for whatever reason, Typesafe will offer builds for Java 6 as part of the commercial subscription.
Now to the version numbers: In the bullet points above we have labeled the version after Akka 2.4 as “Akka <next>” and the reason is that we have received an increasing amount of feedback that we should adopt a semantic versioning scheme, most pointed us towards http://semver.org/. Upon closer inspection we found the precise rules on that site to be inapplicable to a multi-subproject platform that Akka is, especially when also considering our external dependencies that do not abide by these rules either. The main issue that was brought up is that people were surprised that upgrading from 2.2.x to 2.3.x required changes in their part—we broke existing programs in what they felt was a minor release. Our scheme has always been epoch.major.minor but obviously that does not match the expectations of most people, especially not those outside of the Scala ecosystem. Therefore we will adopt a major.minor.patch version scheme after 2.4.0, and instead of the rather complicated semver rules we will simply say:
The published roadmap has been updated to reflect these changes. Please let us know if you have any questions or feedback!
