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