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 > > > > > > > > > > > > > > > > > > >
