You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Alexey Serbin (Jira)" <ji...@apache.org> on 2020/12/03 02:08:00 UTC
[jira] [Updated] (KUDU-1944) Breaking changes best suited for a
Kudu major release (i.e. 2.0)
[ https://issues.apache.org/jira/browse/KUDU-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexey Serbin updated KUDU-1944:
--------------------------------
Description:
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.
h4. Remove std:: classes from C++ client API
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.
h4. Rework Java client async API
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.
h4. Rework status/error codes
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. In addition, generic RPC and application-level RPC errors is messy, and handling RPC's error paths is a pain.
was:
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.
h4. Remove std:: classes from C++ client API
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.
h4. Rework Java client async API
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.
h4. Rework status/error codes
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.
> Breaking changes best suited for a Kudu major release (i.e. 2.0)
> ----------------------------------------------------------------
>
> Key: KUDU-1944
> URL: https://issues.apache.org/jira/browse/KUDU-1944
> Project: Kudu
> Issue Type: New Feature
> Components: api, client, master, tserver
> Affects Versions: 1.3.0
> Reporter: Adar Dembo
> Priority: Major
>
> 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.
> h4. Remove std:: classes from C++ client API
> 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.
> h4. Rework Java client async API
> 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.
> h4. Rework status/error codes
> 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. In addition, generic RPC and application-level RPC errors is messy, and handling RPC's error paths is a pain.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)