-
Notifications
You must be signed in to change notification settings - Fork 579
experimental API policy #218
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a user, some questions I would have:
- How will this be enforced?
- I was using the experimental ABC API, and it was non-compliant because of XYZ. Why did that happen?What recourse do I have?
Co-Authored-By: Martin Wicke <[email protected]>
Co-Authored-By: Martin Wicke <[email protected]>
By the same API review process we use to enforce our other API policies? Or did you mean something else (like: "will we write tools to introspect into these APIs?", to which the answer is yes, soon)
I think this policy says that we cannot remove experimental APIs that break people without a lot of warning (or at all, if we cannot find a good replacement), so it's on us to fix noncompliant APIs as much as we can. |
No, external contributors can contribute to tf.experimental too.
…On Mon, Apr 6, 2020 at 9:31 AM bhack ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In governance/api-reviews.md
<#218 (comment)>:
> +
+No API with known deficiencies should be added to experimental. Experimental
+APIs should, to the best of our knowledge, not be expected to change in a known
+way (no argument with a known bad name, etc). Experimental can, however, be used
+for APIs which are a work-in-progress: it's fine to add experimental methods to
+a base class even if those methods are only implemented on some subclasses as
+long as we expect all classes to eventually implement those.
+
+The same amount of due diligence required for a real API is required for an
+experimental API: this means tests, benchmarks, documentation, end-to-end
+examples, etc
+
+Experimental APIs are not a license to break users. This means:
+ 1. we do not remove experimental APIs which are widely used without an effort
+ to help migrate users away
+ 2. experimental APIs are not removed without warning and don't have
Ok but it is still not clear to me if an external contributor need to
contribute in tf.exeperimental or in tfa. Is this tf.foo.experimetnal
policy reserved to Google employee?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#218 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAABHRNGJW2WQCYYUJS5IDTRLH7W3ANCNFSM4LMPCH6A>
.
--
- Alex
|
@@ -202,7 +202,10 @@ prefer experimental namespaces when possible, so prefer | |||
|
|||
Experimental APIs are APIs intended to be added to TensorFlow as-is, but which | |||
we reserve the right to change in backwards-incompatible ways if we have | |||
to. | |||
to. This is different from apis in `tensorflow/addons`, many of which are not |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this makes it more clear - thanks!
No description provided.