Eventually I think we should get to a place where we can consider the C# API "stable". At that time, I don't think breaking API changes would be acceptable. But I don't think we are there yet.
Of course new public APIs are never considered breaking changes, so any functionality that can be implemented with new APIs can be freely made. Truly breaking changes (ex. removing APIs, renaming APIs, changing parameters/return types, etc) can still be done, but some caution should be used. Breaking changes are hard to consume in .NET. Here is my thought process around breaking changes: 1. Is it truly required that a break MUST be done? Or can the desired functionality be achieved with a new API? 2. Can the existing API still exist, but be marked Obsolete? - This at least gives consumers a period of time where their code still works, but produces a warning. And they can choose to switch to the new API. 3. If it isn't feasible to make the change without breaking an API, we should look at the impact of it. - For example, is it frequently used? Does the new change give enough value to justify the break? Note, these are just my opinions. I'd like to hear others' thoughts as well. Eric Erhardt -----Original Message----- From: Adam Szmigin <adam.szmi...@xsco.net> Sent: Monday, April 27, 2020 7:10 AM To: dev@arrow.apache.org Subject: [EXTERNAL] C# - Appetite for breaking changes to public API? Dear team, I am keen to work on a number of the tickets relating to the C# implementation for Apache Arrow. Quite a few of the open tickets relate to making breaking changes to the public API (e.g. ARROW-7757, ARROW-8581, likely ARROW-6603 as well). What is the general appetite for making breaking changes to the C# code in its present state? The README.md hints at the C# implementation being alpha-grade at present, so I assume all ok, but I would like to check opinions from the devs before I embark on any PRs. Many thanks, -- Adam Szmigin