Hi Team, I'd like to bring this thread back to the top. Aside from the long-term plan to separate the release, are we still considering a quick nightly release to unblock users, or are we ok to wait for the next scheduled release (seems the next scheduled release is around Aug 20th) ?
Be On Mon, Jul 14, 2025 at 11:38 AM yun zou <yunzou.colost...@gmail.com> wrote: > 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 >> > > > > > > >> > > > > >> > >> >
