Hi Max,
Thanks for the pointer. It might be useful in the future indeed.
(though we may just as well rely on conventions, and let each Arrow
implementation decide what facilities they want to expose)
Regards
Antoine.
Le 02/09/2026 à 03:56, Max Burke a écrit :
Hi!
Apologies if this is the wrong thread but there is a proposal open for
flatbuffers to create a "deprecated readonly" attribute that keeps
generating getters for the attributed field but prevents the generation of
the setters, so data that includes this field is unaffected but new data
can't use it.
https://github.com/google/flatbuffers/pull/8192
Figured I'd highlight this if anyone wishes to voice their support, it
seems like it might be a good match :-)
On Tue, Sep 1, 2026 at 2:23 PM Raúl Cumplido <[email protected]> wrote:
+1 (binding)
El mar, 1 sept 2026, 23:02, Sutou Kouhei <[email protected]> escribió:
+1 (binding)
In <[email protected]>
"[VOTE] Informal deprecation of Tensor and SparseTensor in IPC" on Tue,
1 Sep 2026 16:30:36 +0200,
Antoine Pitrou <[email protected]> wrote:
Hello,
This is a vote about the informal deprecation of Tensor and
SparseTensor messages in the IPC protocol. This was previously
discussed in
https://lists.apache.org/thread/z2kl4g1353mbtgpt3qo7j3bzohq0q7fv
Here is the proposal:
1) informally deprecate Tensor and SparseTensor-related IPC messages
in the IPC protocol description and the IPC Flatbuffers definitions
(the Flatbuffers deprecation mechanism is *not* used for now because
it would break existing usage:
https://flatbuffers.dev/evolution/#removal)
2) encourage Arrow implementations to deprecate (and possibly remove)
APIs for reading and writing Tensor / SparseTensor metadata and data
using the IPC protocol.
The vote will be open for at least 72 hours.
[ ] +1 to the proposal
[ ] +0
[ ] -1 to the proposal because ...
Regards
Antoine.
