With 18 issues to close before everything that’s supposed to land in the second major TensorFlow release is done, the team behind the popular machine learning library has taken a moment to let everyone in on what’s planned for the big 2.0.
Although not a lot has changed since the roadmap presented in August 2018, the advent to the first release candidate (supposed to drop in early 2019…so soonish?) brings more details to light and gives a better idea about what developers will have to deal with.
As mentioned back then, the TensorFlow project subscribes to the school of semantic versioning, which is why the team isn’t only adding functionality, but also using the major release to clean up and reiterate on a couple of things which will lead to incompatibility. For example, a couple of APIs such as tf.app, tf.flags, and tf.logging will be removed, mainly because the Python Abseil Common Libraries are open source now, while others have been replaced by their 2.0 equivalents or moved into subpackages.
But before panic starts spreading: SavedModels and GraphDefs will stay backwards compatible, and yes, the team is offering an upgrade script to update code or at least point out segments that need some manual work to run as usual. For tougher cases there’ll always be the compatibility module, which will make sure 1.x code will stay functional during the lifetime of TensorFlow 2.x. Since migrating might take a while, there will even be 12 months of security fixes to the last release of the 1.x series, just so that everyone stays secure in the meantime.
Back to what will change, though: The release focuses on ease of use and simplicity, which is probably necessary to win new developers over. Since object orientation seems to be the order of the day for the new TensorFlow, the team will use v2.0 to get rid of global namespaces and the mechanisms used to find variables that went along with it. It all will be replaced by an appeal to users to keep track of tf.Variable and letting the garbage collector taking care of it otherwise. Keras objects are supposed to lessen the variable tracking burden and the whole process should leave the project with clearer, more reasonable semantic.
Since an implementation of the Keras API will serve as a central high-level API to the library to make model building easier, its details eager execution and tf.data are amongst the most notable additions. The latter will serve as a replacement for queue runners and help with building scalable input pipelines, while eager execution should, amongst other things, speed up the iteration and debugging process by evaluation operations without building graphs.
To make most of the upcoming major release, developers are advised to refactor their code into smaller functions and call them as needed. Other tips include the use of Keras layers to manage variables, and tf.metrics and tf.summary for the aggregation and logging of data. More recommendations and details can be found in the project’s documentation.