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