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