I thought it might be useful to start a list of all Kudu features or additions that we suspect may be breaking (i.e. may break client API/ABI compatibility, wire compatibility, on-disk compatibility, etc.) and should be reserved for a Kudu major release, where we could expect to tolerate such breakages.
Here are a few candidates off the top of my head.
The presence of std:: classes complicates maintenance of ABI compatibility w.r.t. libstdc++. Couple options here:
- Replace std:: classes with simpler primitives (i.e. std::string -> void * + size_t).
- Replace std:: classes with Kudu counterparts (i.e. std::string -> faststring).
- Replace entire C++ API with a C-based API.
- Add a C-based API but retain C++ API as header-only.
I believe all of these break ABI compatibility and likely API compatibility too.
When we first released Kudu 1.0 we thought about stabilizing the async Java API (i.e. all public classes that start with Async), but decided against it because we had no good use cases. If we were to do that now, we'd most certainly be breaking ABI/API compatibility for anyone using it in its current form.
This one also comes up from time to time. It bemoans the coarse grainedness of Status' error codes and, depending on how its done, may break client ABI/API compatibility as well as wire compatibility.