Hello Alva,
This is a reasonable request, but it might come with its own drawbacks
as well.
One significant drawback is that adding the Swift implementation to the
cross-implementation integration tests will be slightly more complicated.
It is very important that all Arrow implementations a
To summarize the discussion so far:
* Some Arrow Java users are still on JDK 8
* Arrow v14 is proposed as the final version with JDK 8 support
* Arrow v14 can support patch releases if necessary for JDK 8 users
* There is an open question to decide if JDK 11 should be dropped
simultaneously
Gang
Hi Antoine,
Thanks for the reply.
It would be great to get the Swift implementation added to the integration
test. I have a task for adding the C Data Interface and I will work on getting
the integration test running for Swift after that task. Can we move forward
with setting up the repo a
Hello Arrow devs,
We are winding down discussion and review. I have created a rendered
version of the proposed protocol: [1]
Feel free to add feedback in the PR [2] or on this thread.
Best,
Will Jones
[1]
http://crossbow.voltrondata.com/pr_docs/37797/format/CDataInterface/PyCapsuleInterface.htm
Hi Alva,
I'll let others give their opinions on the repo.
Regards
Antoine.
Le 10/10/2023 à 19:25, Alva Bandy a écrit :
Hi Antoine,
Thanks for the reply.
It would be great to get the Swift implementation added to the integration
test. I have a task for adding the C Data Interface and I
Hi Alva,
I would encourage you to do whatever will make life more pleasant for
you and other contributors to the Swift Arrow implementation. I have
found development of an Arrow subproject (nanoarrow) in a separate
repository very pleasant. While I don't run integration tests there,
it's not becau
+1 on Dewey's sentiment.
With regards to technicalities:
- a PMC member can create the repo via ASF's gitbox (I assume
'arrow-swift'?)
- the repo then needs to be configured using the '.asf.yaml'
- which merge styles are allowed
- branch protection rules
- to which ml should notifications be
I'm -0 on this without more reasoning. I don't think a large download is a
compelling reason to split the repo, and being in the same repo doesn't mean
you have to take a dependency on the C++ implementation. (Plus, unless there is
enough of a community to replicate all the work done for C++ I s
I agree that we have to move on. It seems that patch release to
Arrow v14 is a good idea, though I cannot estimate the effort to
backport large features like the new layouts that are currently
being added (e.g. RunEndEncoding, ListView, etc.).
As an Arrow developer, I am always happy to drop JDK 8
Hi,
I'm OK with this if we can keep following the Apache Way:
* https://www.apache.org/theapacheway/
* https://theapacheway.com/
Can we discuss how to develop with separated arrow-swift
repository after we re-read the above documentations?
FYI: Here are discussions for arrow-rs and arrow-julia
> I cannot estimate the effort to backport large features like the new
layouts that are currently being added (e.g. RunEndEncoding, ListView,
etc.).
In my mind we are only talking about patch releases for security fixes or
similarly critical issues as otherwise the effort to maintain 'v14' (but
ac
Hey everyone,
Great to bring this up. I can speak for the Iceberg community, and we
expect to support Java 8 for a long time there (unfortunately). Let me go
over some of the arguments here.
Java 8 does have a long Extended Support timeline, but a recent
> report shows Java 11 increasing in adopt
12 matches
Mail list logo
