Github user markhamstra commented on the issue:
https://github.com/apache/spark/pull/21598
> case by case
Yes, but... this by itself makes the decision appear far too discretionary.
Instead, in any PR where you are changing the published interface or behavior
of part of Spark's public API, you should be highlighting the change for
additional review and providing a really strong argument for why we cannot
retain the prior interface and/or default behavior. It is simply not up to an
individual committer to decide on their own discretion that the public API
should be different than what it, in fact, is. Changing the public API is a big
deal -- which is why most additions to the public API should, in my opinion,
come in with InterfaceStability annotation that will allow us to change them
before a new major-number release.
This doesn't apply to changes to internal APIs. Neither does it apply to
bug fixes where Spark isn't actually doing what the public API says it is
supposed to do -- although in cases where we expect that users have come to
safely rely upon certain buggy behavior, we may choose to retain that buggy
behavior under a new configuration setting.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
