Github user shivaram commented on the issue:
https://github.com/apache/spark/pull/16623
Thanks for cc'ing me on this - I think @jkbradley has a good point that we
should be a bit more explicit in discussing when / why we backport changes in
SparkR. While we have not declared it a stable interface, I think the number of
users who are using it is large enough now that there is some expectation of
stability.
I think we can easily separate out the fixes we backport into a couple of
buckets -- changes like
https://github.com/apache/spark/commit/7763b0b8bd33b0baa99434136528efb5de261919
which are internal changes and don't affect the API / are bug fixes fixing the
behavior of an existing API. My reading of our [versioning
policy](http://spark.apache.org/versioning-policy.html) is that these are
expected in a feature release.
The second group are changes that either add or modify an API (we should
never backport something that removes an API). For the modifications, lets
explicitly discuss in the JIRA / Github PR as to why this is necessary / a good
idea and also if its source compatible (e.g.,
https://github.com/apache/spark/commit/06e77e0097c6fa0accc5d9d6ce08a65a3828b878
is source compatible)
The other thing we could do is add JIRA labels like regression / bug-fix /
api-modify to each JIRA that gets backported. Does that sound like something
that would be useful @jkbradley @felixcheung ?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
