Re: [PROPOSAL] Regular release pace & some post release actions

Just to be concrete about "regular & predictable releases pace", the proposal is to have one line on https://iceberg.apache.org/releases/ like this: "Apache Iceberg releases are expected every quarter. Next target release is 1.4.1 planned on Jan 24." To be honest, only a few Apache projects do th

Re: [PROPOSAL] Regular release pace & some post release actions

I think there are two kinds of releases: 1. Feature release. That means to upgrade the minor part of the version number, e.g. 1.4.0, 1.5.0, etc. 2. Patch release. That's bug fixes to minor releases, which upgrades to the last part of each release version, e.g. 1.4.1, 1.4.2. I think the quarterly r

Re: Proposal: Introduce deletion vector file to reduce write amplification

Hi: I have addressed most comments in the document. I would like to ask what's the next step? Should we have a vote on this spec to reject it or we should go on with it? On Sat, Sep 30, 2023 at 11:20 PM Renjie Liu wrote: > Hi: > Sorry for the late reply, I have been busy recently. I've updated t

Re: Scan column metrics

I am sure dropping column stats can be helpful. Just that it has some challenges in practice. It requires table owners to know the query pattern and decide what column stats to keep and what to drop. While automation can help ease the decisions based on the query history, it can't predict future us

Re: [PROPOSAL] Regular release pace & some post release actions

Yes, agree. Patch release is whenever needed. The pace is more for « feature releases » and also the information on website. Regards JB Le sam. 7 oct. 2023 à 11:41, Renjie Liu a écrit : > I think there are two kinds of releases: > 1. Feature release. That means to upgrade the minor part of the

Re: [PROPOSAL] Regular release pace & some post release actions

My 2ct, There is no harm in stating it explicitly, however, I'm not in favor of making it so explicit by pinning a date onto it (Jan 24). I would rather say that releases can be expected at least every quarter (so it doesn't need to be updated :) I noticed that the releases of Iceberg are also dr

Re: [PROPOSAL] Regular release pace & some post release actions

I would agree with Fokko here. We want flexibility with releases and tracking to specific dates on the website just lends to unnecessary process. We also tend to track the release progress using github milestones especially as we get closer to the release date, which provides more context. Track

Re: [PROPOSAL] Regular release pace & some post release actions

There is also one post-upgrade that I would like to propose: https://github.com/apache/iceberg-docs/pull/280 We publish the releases also at Github , and I think that also gives a nice changelog. Now Python is in its own repository, no need to clean up th

Re: [PROPOSAL] Regular release pace & some post release actions

It makes sense. A statement on website with « release every quarter » would be great ! +1 Regards JB Le sam. 7 oct. 2023 à 20:09, Fokko Driesprong a écrit : > My 2ct, > > There is no harm in stating it explicitly, however, I'm not in favor of > making it so explicit by pinning a date onto it (