Oh, sorry for introducing wrong instruction. (merging into
release-6.0.0.)
In
"Re: [VOTE][RESULT] Release Apache Arrow 6.0.0 - RC3" on Wed, 3 Nov 2021
13:24:05 +0100,
Krisztián Szűcs wrote:
> On Tue, Nov 2, 2021 at 7:27 PM Matthew Topol wrote:
>>
>> The patch to the release-6.0.0 branch
Homebrew packages are updated. I've uploaded RubyGems.
Conda and vcpkg are still work-in-progress?
1. [done] bump version numbers
2. [done] upload source
3. [done] upload binaries
4. [done] update website
5. [done] upload ruby gems
6. [done] upload js packages
8. [done] upload C# packages
10.
Hey Alessandro, take a look at the top level docs on ValueVector:
https://arrow.apache.org/docs/java/reference/org/apache/arrow/vector/ValueVector.html
Specifically the following:
- values need to be written in order (e.g. index 0, 1, 2, 5)
- null vectors start with all values as null
TDLR: does anyone have time for feedback / review on a PR [1] to add
argument validation to ArrayData? I believe it a necessary (but not
sufficient) step to harden the arrow-rs implementation
Background:
As many of you may remember, there have been various ongoing discussions[2]
about aspects of
The vote passes with 3 +1 votes and no other votes.
The release is available here:
https://dist.apache.org/repos/dist/release/arrow/arrow-rs-6.1.0
The code has also been released to crates.io:
https://crates.io/crates/arrow/6.1.0
https://crates.io/crates/arrow-flight/6.1.0
+1
Ran the verification script on aarch64-apple-darwin.
Neal
On Wed, Nov 3, 2021 at 2:29 PM Andrew Lamb wrote:
> Does anyone from the PMC have time to weigh in on the 6.1.0 Rust Arrow
> release candidate? I would like to either release it, or decide we
> shouldn't.
>
> It is currently in a
Does anyone from the PMC have time to weigh in on the 6.1.0 Rust Arrow
release candidate? I would like to either release it, or decide we
shouldn't.
It is currently in a limbo state with 2 +1 votes (not yet at the 3 +1s
needed to release) but also no -1 or +0 votes
Andrew
On Tue, Nov 2, 2021 at
I think the c data interface requires the arrays to be immutable or two
implementations will race when mutating/reading the shared regions, since
we have no mechanism to synchronize read/write access across the boundary.
Best,
Jorge
On Wed, Nov 3, 2021 at 1:50 PM Alessandro Molina <
Ah, thanks for the clarification Krisztián, and for creating the maint-6.0.x
branch. As far as ARROW-14493 that you linked to, that should get shifted to
being Fix Version 7.0.0.
Since ARROW-14513 was resolved and cherry-picked, and the script on that branch
will publish the go/v6.0.1 tag for
Thank you, Micah. We plan to rewrite a lot of the API in Arrow 7 so I think
option 1 would add a lot of overhead. I added a note to the Arrow 6 release
notes in https://github.com/apache/arrow-site/pull/153/files#r741928109.
On Nov 2, 2021 at 22:30:01, Micah Kornfield wrote:
> I'd suggest maybe
Thank you, Micah. We plan to rewrite a lot of the API in Arrow 7 so I
think option 1 would add a lot of overhead. I added a note to the Arrow 6
release notes in
https://github.com/apache/arrow-site/pull/153/files#r741928109.
On Nov 2, 2021 at 22:30:01, Micah Kornfield wrote:
> I'd suggest
I recently noticed that in the Java implementation we expose a set/setSafe
function that allows to mutate Arrow Arrays [1]
This seems to be at odds with the general design of the C++ (and by
consequence Python and R) library where Arrays are immutable and can be
modified only through compute
On Tue, Nov 2, 2021 at 7:27 PM Matthew Topol wrote:
>
> The patch to the release-6.0.0 branch to fix the Go issue has been merged and
> is ready for a 6.0.1 release once everything else is.
Actually the release branches are only used for the actual release,
this allows the main branch to receive
13 matches
Mail list logo
