[
https://issues.apache.org/jira/browse/KUDU-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16785095#comment-16785095
]
Andrew Wong commented on KUDU-1944:
-----------------------------------
Remove the various deprecated pieces of our public API.
Notably, any PB field that gets auto-generated in the Java client will expose a
deprecated, but still useable method as a part of the public API.
[{{DEPRECATED_range_predicates}}|https://gerrit.cloudera.org/c/12661/] in
{{NewScanRequestPB}}, and the resulting {{addColumnRangePredicatesRaw}} and
{{addColumnRangePredicate}} methods in {{AbstractKuduScannerBuilder}}, are an
example of this.
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
