Hi folks Here is a tentative solution: https://github.com/apache/polaris/pull/3515
This is currently developed as a standalone script so that we can quickly provide a workaround for #3500. This would work with your proposed step-by-step process, JB. The script (or its integration in automated workflows) would be run before we vote for a release. Let me know what you think Cheers -- Pierre On Fri, Jan 23, 2026 at 10:28 AM Jean-Baptiste Onofré <[email protected]> wrote: > Hi, > > That works for me. > In terms of the release process, I think it would be easier: > 1. To maintain the "aggregate" index on dist dev ( > > https://dist.apache.org/repos/dist/dev/incubator/polaris/helm-chart/index.yaml > ), > with the latest release using downloads.apache.org and all previous > releases using archive.apache.org > 2. When we stage a new release (for vote), we update the index on dist dev > 3. When we "promote" the release, we copy the index from dist dev to dist > release ( > > https://dist.apache.org/repos/dist/release/incubator/polaris/helm-chart/index.yaml > ) > With this approach, we will review and release artifacts (includes index) > that we publish. > > Just my $0.01 > > Regards > JB > > On Fri, Jan 23, 2026 at 10:19 AM Alexandre Dutra <[email protected]> > wrote: > > > Hi all, > > > > I think that the workflow suggested by Dmitri is the best in terms of UX. > > > > As for fixing the current state of things, what Pierre suggested seems > > like a quick win: regenerate an index that spans the two servers and > > publish it to dist > > release so that it replaces the one on download.a.o. > > > > Thanks, > > Alex > > > > On Thu, Jan 22, 2026 at 7:02 PM Jean-Baptiste Onofré <[email protected]> > > wrote: > > > > > > Hi, > > > > > > We can argue that the index file is similar to the KEYS file and not > > > strictly part of the release. > > > > > > Theoretically, every artifact we publish should be voted on and remain > > > unchanged after the vote. This is why I suggested updating the > aggregated > > > index as part of the release currently under review. > > > > > > I believe this approach should work. > > > > > > Regards, > > > JB > > > > > > On Thu, Jan 22, 2026 at 6:58 PM Pierre Laporte <[email protected]> > > > wrote: > > > > > > > Thanks Robert for opening this thread. > > > > > > > > Regarding attaching the binary artifacts to GitHub releases, here is > > some > > > > good news: it is already the case :-). You can see that the source, > > binary > > > > tarballs as well as helm chart are attached to the 1.3.0 Github > Release > > > > [1]. That being said the file names are not great, let me open an > > issue > > > > for that. > > > > > > > > As for creating a Helm index that references charts across > > downloads.a.o > > > > and archive.a.o, I think it should be fairly easy to do. It can > > certainly > > > > be included as part of the release automation. > > > > > > > > For me the big question is: can we fix the user-facing issue asap? > As > > far > > > > as I can tell, we could either: > > > > * Restore the previous binaries in dist release by performing a > couple > > of > > > > `svn revert` commands > > > > * Regenerate an index that spans the two servers and publish it to > dist > > > > release so that it replaces the one on download.a.o > > > > > > > > JB, would it be possible to publish the index.yaml file to > dist/release > > > > without requiring voting on dev and on the incubator? Technically, > the > > > > file that is on dist release has been generated after the incubator > > vote > > > > was closed. So I think we could argue it is not part of any specific > > > > release. Wdyt? > > > > > > > > [1] > > > > > > > > > > > https://github.com/apache/polaris/releases/tag/apache-polaris-1.3.0-incubating > > > > -- > > > > > > > > Pierre > > > > > > > > > > > > On Thu, Jan 22, 2026 at 5:28 PM Jean-Baptiste Onofré < > [email protected]> > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > index is already on downloads.apache.org ( > > > > > > > > > > > > > > > > > https://dist.apache.org/repos/dist/release/incubator/polaris/helm-chart/index.yaml > > > > > , dist is basically the "driver" of downloads.apache.org). > > > > > > > > > > I see only two possible options: > > > > > - we don't provide the Helm index (it's what Airflow is doing > > afair), but > > > > > the user experience is not great (helm repo add would not work "out > > of > > > > the > > > > > box") > > > > > - we create aggregate Helm index when staging a release, and so we > > keep > > > > the > > > > > index up to date, to be updated on downloads/dist release > > > > > > > > > > Regards > > > > > JB > > > > > > > > > > On Thu, Jan 22, 2026 at 5:23 PM Dmitri Bourlatchkov < > > [email protected]> > > > > > wrote: > > > > > > > > > > > Thanks for opening this discussion, Robert! It definitely looks > > like we > > > > > can > > > > > > improve helm UX. > > > > > > > > > > > > All: > > > > > > > > > > > > WDYT about hosting helm index for all supported releases on > > > > > > downloads.apache.org (as before), but moving old charts to the > > > > archive? > > > > > > > > > > > > When a new RC comes out it will have helm index updates according > > to > > > > what > > > > > > version is the latest at the time of release and some links > > > > (re-)pointing > > > > > > to the archive. When the RC is approved, its helm index will > simply > > > > > replace > > > > > > the old one on downloads.apache.org. > > > > > > > > > > > > The archive site will _not_ have a helm index, only chart tar > > files, > > > > > > signatures, etc. > > > > > > > > > > > > Link changes should not be a problem for automated tools, I hope. > > > > > > > > > > > > The helm index will be truncated as the community decides to > > > > "unsupport" > > > > > > old releases (with proper release note notifications, etc.). > > > > > > > > > > > > Cheers, > > > > > > Dmitri. > > > > > > > > > > > > On Thu, Jan 22, 2026 at 6:43 AM Robert Stupp <[email protected]> > > wrote: > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > The issue #3500 mentions an issue with (perma)links to Helm > > charts to > > > > > > > downloads.a.o. Once a new release is published, the previously > > > > working > > > > > > link > > > > > > > will no longer work, as old releases, although available on > > > > archive.a.o > > > > > > get > > > > > > > removed from downloads.a.o. That's just how it works. > > > > > > > > > > > > > > For helm charts referenced by their URL and potential > > user-automation > > > > > to > > > > > > > grab other binary artifacts, a new release kind-of "suddenly" > > breaks > > > > > user > > > > > > > environments/workflows. > > > > > > > > > > > > > > What do you guys think about the following? > > > > > > > > > > > > > > We can attach the binary artifacts to GitHub releases and/or > > publish > > > > > > those > > > > > > > to Maven Central - and adjust the documented download links to > > either > > > > > of > > > > > > > these locations? > > > > > > > > > > > > > > For the Helm charts, the situation is a bit more complex, > > because of > > > > > the > > > > > > > index.yaml. While it is correct on downloads.a.o [1], the one > on > > > > > > > archive.a.o [2] is missing older releases. But since the > content > > of > > > > > > > archive.a.o is taken from downloads.a.o, there's not much we > can > > do > > > > > about > > > > > > > it. > > > > > > > An option could be to have an index.yaml elsewhere, potentially > > on a > > > > > > > separate web site like https://polaris-charts.apache.org/ that > > only > > > > > > > contains an ever-growing index.yaml file, which is updated > > during a > > > > > > release > > > > > > > publication using 'helm repo index . --merge index.yaml --url > > ...', > > > > > where > > > > > > > that URL points to the helm package, which can be a GitHub > > release > > > > > > artifact > > > > > > > or some other location. > > > > > > > > > > > > > > Robert > > > > > > > > > > > > > > [3500] https://github.com/apache/polaris/issues/3500 > > > > > > > [1] > > > > > > https://downloads.apache.org/incubator/polaris/helm-chart/index.yaml > > > > > > > [2] > > > > > > > > > > > > > > https://archive.apache.org/dist/incubator/polaris/helm-chart/index.yaml > > > > > > > > > > > > > > > > > > > > > > > > >
