Andrew, what do you think about tweeting this series out through @ApacheArrow?
-David
On Mon, Oct 17, 2022, at 16:50, Andrew Lamb wrote:
> And the final installment:
> https://arrow.apache.org/blog/2022/10/17/arrow-parquet-encoding-part-3/
>
> On Sat, Oct 8, 2022 at 9:47 AM Andrew Lamb wrote:
>
I agree with Will's suggestion, and I also suggest that another type we
should always backport would be any identified security vulnerability or
issue.
--Matt
On Wed, Oct 19, 2022 at 1:48 PM Will Jones wrote:
> One particular type of defect we might want to consider backporting to
> supported v
One particular type of defect we might want to consider backporting to
supported versions are ones that silently produce incorrect data. Unlike
ones that cause a crash, it's not easy for a user to know they are affected.
Here are a few examples:
* ARROW-17453: [Go][C++][Parquet] Inconsistent Dat
Hi,
I've been thinking a lot about maintenance and lifecycle policies and
defect classification recently - I'm very grateful this is being raised. I
believe establishing such policies will prove instrumental to enable
adoption of Arrow for a number of use cases that prioritize stability over
innov
I added the DataFusion 13.0.0 release and created PRs to update release
instructions for both repos:
https://github.com/apache/arrow-datafusion/pull/3893
https://github.com/apache/arrow-ballista/pull/401
On Tue, Oct 11, 2022 at 6:29 AM Andy Grove wrote:
> Hi Kou,
>
> Sure. I will look into this
Hi Kou,
Le 19/10/2022 à 06:29, Sutou Kouhei a écrit :
My proposal: We maintain the last major release:
* We maintain 9.Y.Z when the latest major release is 9.0.0
* We may release 9.Y.Z when we find a problem such as a
security vulnerability in 9.Y.Z
* We drop support for 9.Y.Z when we rele
