This topic was discussed in the Arrow sync call this week. See the
notes from that call here:
https://lists.apache.org/thread/gbywpzbvpfydq24m1c0w6jgybnsrf9xm
Ian
On Wed, Nov 23, 2022 at 7:36 AM Benson Muite wrote:
>
> On 10/19/22 20:47, Will Jones wrote:
> > One particular type of defect we mig
On 10/19/22 20:47, Will Jones wrote:
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-17
ded shell scripts for some
post release tasks (updating MSYS2/Homebrew/vcpkg packages)
in the 10.0.0 release. Release costs will be reduced in
future releases.
Thanks,
--
kou
In
"Re: [DISCUSS] Maintenance policy" on Wed, 19 Oct 2022 10:47:51 -0700,
Will Jones wrote:
> One part
es, we release not only source but also
.deb/.rpm/.wheel/... and so on.
Thanks,
--
kou
In
"Re: [DISCUSS] Maintenance policy" on Wed, 19 Oct 2022 10:32:13 -0600,
Todd Farmer wrote:
> Hi,
>
> I've been thinking a lot about maintenance and lifecycle policies and
> def
ter lubridate 1.9 release
Thanks,
--
kou
In <0f814dd3-2462-3fa9-e34b-38fe43140...@python.org>
"Re: [DISCUSS] Maintenance policy" on Wed, 19 Oct 2022 13:41:42 +0200,
Antoine Pitrou wrote:
>
> Hi Kou,
>
> Le 19/10/2022 à 06:29, Sutou Kouhei a écrit :
>> My pro
On Thu, Oct 20, 2022 at 11:31 AM Jacob Wujciak
wrote:
> This is definitively an important topic that should be discussed. I just
> want to point out that there is no difference between a major, minor or
> patch release with regards to the ASF process. Any official release needs a
> vote and a PMC
This is definitively an important topic that should be discussed. I just
want to point out that there is no difference between a major, minor or
patch release with regards to the ASF process. Any official release needs a
vote and a PMC to act as a release manager to sign & upload the release
(which
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
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
Hi,
Can we define our maintenance policy?
For example, we maintain the last 3 major releases:
* We maintain 7.Y.Z, 8.Y.Z and 9.Y.Z when the latest major
release is 9.0.0
* We may release 7.Y.Z, 8.Y.Z or 9.Y.Z when we find a
problem such as a security vulnerability in 7.Y.Z, 8.Y.Z or
9.Y.Z
*
12 matches
Mail list logo
