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 <[email protected]>
Sent: Monday, April 27, 2020 7:10 AM
To: [email protected]
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
