If we decide to adopt an independent release cadence for the Helm chart, it might be more intuitive to host it in a separate repository. While this would increase the effort required to maintain compatibility between Helm chart releases and Polaris releases—particularly around testing and documentation—it could be a worthwhile trade-off if we start seeing frequent divergence in release timelines between the two (whether the chart moves faster or slower). That said, if Polaris continues to release at a fast pace, the added complexity may not be necessary.
In parallel with this discussion on separate release cadences for the Helm chart, another important point raised in this thread is whether we should consider doing nightly build releases in the short term? This could help address the JDBC use case mentioned here: https://github.com/apache/polaris/issues/2030. might be helpful in unblocking that use case and could support onboarding more users ahead of the next official Polaris release. Best Regards, Yun On Mon, Jul 14, 2025 at 10:42 AM Dmitri Bourlatchkov <di...@apache.org> wrote: > I also think that the compatibility between helm charts and Polaris > binaries will need more attention if we use a separate repository. > > However, from my POV I'd expect helm charts to get changes / contributions > independently of the Polaris Server code (for all sorts of deployment > choices), so having it in a separate repository is probably going to make > maintenance easier (to recap: I originally supported more frequent / > independent chart releases too). > > We could release Polaris Server patch releases with Helm changes but > without server code changes, but I guess this kind of release process will > be error-prone and more difficult for release managers (for having to pay > close attention to what needs to be cherry-picked). > > +1 to apache/polaris-helm-chart > > Cheers, > Dmitri. > > On Mon, Jul 14, 2025 at 8:02 AM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > > Hi > > > > I'm fine having a dedicated repo for helm chart, it all depends on > > what we want to release: > > 1. If we just want to release helm charts "package", then helm charts > > can stay in the polaris repo (as so part of the source distribution) > > 2. if we want to release a complete different source distribution and > > package for Helm Charts, then we can have a complete separate > > repository. > > > > Apache projects use both. For instance, Airflow is using (1), whereas > > Pulsar or Ozone are using (2). > > > > If we have a consensus for a separate repo, I would suggest > > apache/polaris-helm-chart repository. I can create. > > > > Regards > > JB > > > > On Mon, Jul 14, 2025 at 1:25 PM Alexandre Dutra <adu...@apache.org> > wrote: > > > > > > Hi all, > > > > > > For reference and completeness, this has also been previously > > > discussed in a much older thread: > > > https://lists.apache.org/thread/428xb6dfrmm7xgr91p2dxoy8ptcyovs2 > > > > > > So far the consensus was, as Yufei pointed out, to release the Helm > > > chart along with the Polaris server release (+docker images, etc.) – > > > mostly for the sake of simplicity. > > > > > > I confess I'm torn on the idea of separate releases and/or moving the > > > chart to the polaris-tools repo. I fear that the chart could quickly > > > lag behind Polaris itself, especially when configuration options > > > change. > > > > > > But if that is now the preferred option, I'm fine with that. > > > > > > Thanks, > > > Alex > > > > > > > > > On Sun, Jul 13, 2025 at 5:27 AM Yong Zheng <yzh...@apache.org> wrote: > > > > > > > > I also likes the idea of moving the chart to a different repo (some > > obvious downsize are we will need to move some work around and duplicate > > some build pipeline etc.). Also, another thing we will loss is the > > published helm doc (assuming we still want it, otherwise, just ask people > > to get the info from README.md from git repo). Other than these, I don't > > have a concern. > > > > > > > > On 2025/07/12 11:21:53 Robert Stupp wrote: > > > > > If the consensus is to have a different release cadences for the > > > > > Polars helm chart and Polaris "server", I propose to move the helm > > > > > charts to polaris-tools. One difference between the two repos is > that > > > > > the "main" repo eventually gets (semi) automatic releases that > might > > > > > get confused with rather manually driven helm-chart releases (it > will > > > > > have to use and check against Git tags and potentially version > > > > > branches). Therefore the polaris-tools repo sounds more > appropriate, > > > > > because there are already multiple "sub projects". > > > > > > > > > > Another reason to move the helm-charts to polaris-tools is that the > > > > > helm-charts, if released independently, become suitable for > multiple > > > > > Polaris versions, which requires tests/CI against multiple Polaris > > > > > versions. Letting pretty much every change to the "main" repository > > > > > trigger CI for a potentially big helm-chart/Polaris test-matrix > seems > > > > > to be an unnecessary waste of CI time. In polaris-tools, all CI > jobs > > > > > are "scoped" to a particular "root path". > > > > > > > > > > Different release cadences also mean to maintain a "compatibility > > > > > matrix", not immediately, but in the (near?) future. > > > > > > > > > > Thoughts? > > > > > > > > > > On Sat, Jul 12, 2025 at 9:08 AM Yufei Gu <flyrain...@gmail.com> > > wrote: > > > > > > > > > > > > Sounds good. I think Apache Airflow did the exact same thing by > > publishing > > > > > > both Helm Chart source and Helm Chart binary package. We still > > need to > > > > > > figure out a few things: > > > > > > 1. What does the Helm Chart version look like? > > > > > > 2. Publishing a version map between Helm Chart and Polaris server > > as the > > > > > > part of Helm Chart doc. For example, Helm Chart version 1.2.0 > > works with > > > > > > Polaris server 0.9.0, 1.0.0, and 1.1.0. > > > > > > 3. What's the default docker image tag? I'd suggest using the > > latest > > > > > > Polaris release version(e.g., 1.0.0-incubating) at the time the > > Helm Chart > > > > > > was published. > > > > > > 4. Location would be easy to decide, we can continue to publish > it > > to > > > > > > dist.apache.org as 1.0.0-incubating did. > > > > > > > > > > > > If we decide to release the Helm chart on its own cadence, we > > don't need a > > > > > > nightly Helm Chart release at this time. > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > On Fri, Jul 11, 2025 at 11:32 PM Jean-Baptiste Onofré < > > j...@nanthrax.net> > > > > > > wrote: > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > It's not a problem for me to release "part" of Polaris like > Helm > > chart. > > > > > > > > > > > > > > However, the release has to be "ASF valid", meaning that the > > release > > > > > > > needs to include source distribution. Today, we don't have > source > > > > > > > distribution only for Helm chart (it's global source > distribution > > > > > > > including Helm sources). > > > > > > > So, I propose to include a source tar gradle task in Helm chart > > (with > > > > > > > signing and checksum). If we do that, no problem. I can take a > > crack > > > > > > > on this :) > > > > > > > > > > > > > > Regards > > > > > > > JB > > > > > > > > > > > > > > On Sat, Jul 12, 2025 at 1:30 AM Yufei Gu <flyrain...@gmail.com > > > > wrote: > > > > > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > > > > > While testing the freshly-minted 1.0.0-incubating release, we > > noticed > > > > > > > > something odd: the Polaris release has relational-jdbc > > persistence, yet > > > > > > > the > > > > > > > > Helm chart only understands the legacy eclipselink. Here is > > the issue: > > > > > > > > https://github.com/apache/polaris/issues/2030. > > > > > > > > > > > > > > > > We previously made the decision to publish Helm Chart with > > Polaris src > > > > > > > and > > > > > > > > bin, check the ML thread: > > > > > > > > > > https://lists.apache.org/thread/d1vf7xpn6nkzp8gbh417m8qb58tkpcqz. We may > > > > > > > > revisit the approach. I think it makes more sense to release > > the Helm > > > > > > > chart > > > > > > > > on its own cadence. Not all Polaris users need Helm charts, > > plus Helm > > > > > > > chart > > > > > > > > tweaking happens commonly between Polaris server releases. > > WDYT? > > > > > > > > > > > > > > > > Meanwhile, we can start to release the nightly Helm Chart as > a > > quick > > > > > > > > solution for any users trying the new release with JDBC > > backend. Thoughts > > > > > > > > and volunteers for this one? > > > > > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > >
