| Status | Proposed |
|---|---|
| Author(s) | Edd Wilder-James ([email protected]), Martin Wicke ([email protected]) |
| Sponsor | Kevin Haas ([email protected]) |
| Updated | 2019-08-16 |
This document describes best practices for numbering versions of projects that form part of the TensorFlow suite of projects. This practice is required for dependent projects hosted under the TensorFlow organization on GitHub, and advisory for dependent projects hosted elsewhere.
"TensorFlow" in this document refers to the core TensorFlow project, as developed in
GitHub tensorflow/tensorflow.
As the number of projects dependent on TensorFlow increases, such as those shipped by SIG Addons or IO, it is helpful to maintainers to understand the constraints on how to number their releases.
All projects must follow semantic versioning.
Until a project reaches 1.0, it does not have to make any backward compatibility guarantees.
Projects should not try to track major TensorFlow versioning to indicate compatibility
with particular TensorFlow releases. Instead, compatibility must be signalled
by the use of dependencies in pip, or whichever package manager is being used by the project.
Within the constraints of semantic versioning, project maintainers should feel free to do whatever is best for their projects and users.
Included as advisory but not binding.
- Jason Zaman: It might be a good idea to also mention stability guarantees, and things that are excluded from them. eg TensorFlow itself says anything that's
tf.foo.experimental.baris not stable and is allowed to change at anytime, and other projects should think about having a similar mechanism if needed.