Re: [VOTE] Amend Spark's Semantic Versioning Policy

This new policy has a good indention, but can we narrow down on the migration from Apache Spark 2.4.5 to Apache Spark 3.0+? I saw that there already exists a reverting PR to bring back Spark 1.4 and 1.5 APIs based on this AS-IS suggestion. The AS-IS policy is clearly mentioning that

Re: [Proposal] Modification to Spark's Semantic Versioning Policy

+1 for Sean's concerns and questions. Bests, Dongjoon. On Fri, Mar 6, 2020 at 3:14 PM Sean Owen wrote: > This thread established some good general principles, illustrated by a few > good examples. It didn't draw specific conclusions about what to add back, > which is why it wasn't at all

Re: [Proposal] Modification to Spark's Semantic Versioning Policy

I want to thank you *Ruifeng Zheng* publicly for his work that lists all the signature differences of Core, SQL and Hive we made in this upcoming release. For details, please read the files attached in SPARK-30982 . I went over these files and

Re: [Proposal] Modification to Spark's Semantic Versioning Policy

+1 for Sean as well. Moreover, as I added a voice on previous thread, if we want to be strict with retaining public API, what we really need to do along with this is having similar level or stricter of policy for adding public API. If we don't apply the policy symmetrically, problems would go

Re: [Proposal] Modification to Spark's Semantic Versioning Policy

Yea, +1 on Jungtaek's suggestion; having the same strict policy for adding new APIs looks nice. > When we making the API changes (e.g., adding the new APIs or changing the existing APIs), we should regularly publish them in the dev list. I am willing to lead this effort, work with my colleagues