Hi, Sorry for not replying to this thread... I was working on post release tasks. It's not completed yet but almost done. I want to get consensus about this to complete the last post release task, "Remove old artifacts". I want to remove unmaintained artifacts from https://dist.apache.org/repos/dist/release/arrow/ .
> That sounds ok to me, but is there a more precise criterion than "we > find a problem"? > > In the past, we have from time to time done maintenance releases based > on annoying bugs/regressions. But not always. How about the followings? - Regression (patch release) - Security vulnerability (patch release or minor release) - New platform support with keeping backward compatibility (minor release) e.g.: - https://issues.apache.org/jira/browse/ARROW-18255 [C++] Support armv6 - https://issues.apache.org/jira/browse/ARROW-17487 [Python][Packaging] 3.11 wheels > I'm afraid "green nightly CI" is more of an ideal than a reality given > the breadth and complexity of our fleet of CI jobs. I think so too. So I think that we need to improve our nightly CI for maintaining multiple major releases. For example, we may want to add "allow-failures" feature to our nightly CI but it may hide our real problems... > there are also regularly regressions due to changes in > third-party packages. Right. So I think that maintenance branches should accept patches for CI that doesn't change library behavior too. They contain CI configuration changes, test changes and so on. e.g.: - https://issues.apache.org/jira/browse/ARROW-18299 [CI][GLib][macOS] Failed to install dependencies by Homebrew - https://issues.apache.org/jira/browse/ARROW-18285 [R] Fix for failing test after 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 <anto...@python.org> wrote: > > 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 release 10.0.0 > > That sounds ok to me, but is there a more precise criterion than "we > find a problem"? > > In the past, we have from time to time done maintenance releases based > on annoying bugs/regressions. But not always. > >> I think that we can maintain multiple major releases with >> not high release cost by implementing the followings: >> * Green nightly CI >> * Nightly CI for all maintained branches (maint-X.Y.Z) >> * We need to reduce the time taken to CI >> * ... > > I'm afraid "green nightly CI" is more of an ideal than a reality given > the breadth and complexity of our fleet of CI jobs. We still seem to > have stability problems in some areas (perhaps Acero?) but there are > also regularly regressions due to changes in third-party packages. > > Regards > > Antoine.
