Tirth Patel

I am +1 for the A1 option. It is a minimalist option without severe backward-compatibility concerns. I have proposed this alternative in #105. @rgommers @mattip @seberg @leofang I'd appreciate your...

> If a new name is created, new C code can indicate that by using `DLManagedTensorVersioned` in headers to give some type/ABI safety. How would one do that? I think...

> And the only way to transition that, is probably to create a new pair of functions that use `DLManagedTensorVersioned *`? As far as C/C++ is concerned, I too think...

> How would this look for A2? We can add new fields onto DLTensor since the version is the first field in DLManagedTensorVersioned (as opposed to A1 where the version...

The idea is to introduce new functions (`to_dlpack(DLManagedTensorVersioned *)` and `from_dlpack(DLManagedTensorVersioned *)`) that convert and export the tensor to a `DLManagedTensorVersioned *`. It's good to have for type safety but...

Without versioning, DLPack can't evolve. There are already requests for read-only data support, non-native endianness, etc. Adding those without a version to separate the new structure will lead to spurious...

Hi everyone, The issue has been up for almost a month. So far, I think @mattip, @seberg, and @leofang are in favor of versioning and @wjakob is against it. Let's...

@wjakob > it would be useful if versioning-related information is appended to data structures so that they are still interpretable by older versions at an ABI level. Yes, this is...

> * It's not clear to me that either solution will be generally helpful. If the vast majority of libraries supporting DLPack do not support non-native byteorder, then an exception...

> I think I have a slight preference for (2) That's what NumPy does right now: ```py >>> import numpy as np >>> x = np.array([1,2,3], dtype='>i2') >>> np.from_dlpack(x) Traceback...