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