Hi Yun I would propose to focus on the following: 1. We have a "isolated" release cycle for Helm Chart 2. We do a Helm Chart release as soon as we need to fix/unblock users
Snapshot is not a release (official one), so, not sure it actually helps (or just for testing purpose). In order to move forward, I propose: 1. Move helm chart in a separate repo (https://github.com/apache/polaris-helm-chart), including the corresponding GH Actions 2. We prepare a new "official" release on this repo If we have a consensus here, I'm happy to tackle that. Thoughts ? Regards JB On Mon, Jul 21, 2025 at 4:14 AM yun zou <yunzou.colost...@gmail.com> wrote: > > Hi all, > > I think we are separating the discussion into two parts: the long term plan > for Helm Chart release, > and the short term plan to mitigate the use issue. > > For the long term, it sounds like we would like to go with a separate release > for Helm Chart, and want to > move Helm Chart to a separate repo. > > For a short term plan, I think we need to answer two questions first: > 1) Whether we think it is important to unblock the use case as soon as > possible? > 2) If we do want to unblock the use case as soon as possible, what would be > the approach to adopt? > > If there are many use cases, and there is still a long time until the next > formal release, it is probably > worth the effort to get an approach to unblock the users soon. > > If we do want to unblock the use case soon, we probably should start the > process as soon as possible, > either the "snapshot" approach or just do a 1.1 release. It seems that people > do prefer to just > release 1.1 with patch. > > Given the fact that we only receive one complaint now, maybe we can wait for > a while to see if there are > more complaints and then decide. > > Best Regards, > Yun > > > > > On Sun, Jul 20, 2025 at 9:48 AM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: >> >> Hi, >> >> I guess you don't mean release, because a release (nightly or not) at >> Apache requires a vote and approval from PPMC + IPMC members. >> If you mean, nightly "snapshots" Helm chart build, it's OK. >> >> However, it should be clearly for testing (it's nightly/snapshot so >> it's not for production). For production, as we plan independent >> release cycle for Helm Chart, we should just do a "regular" release. >> >> Regards >> JB >> >> On Fri, Jul 18, 2025 at 10:39 PM yun zou <yunzou.colost...@gmail.com> wrote: >> > >> > The purpose of a nightly Helm Chart release is to *quickly* unblock users, >> > as in this issue: https://github.com/apache/polaris/issues/2030. >> > >> > The release process for the nightly Helm Chart would follow the same >> > approach >> > as the current one—the main difference is that we’d need to publish it to >> > a >> > separate release repository. As @Jean-Baptiste Onofré mentioned, we also >> > need to include the source in the release, which is not done yet. >> > >> > Alternatively, we could opt for a formal 1.0.1 release if that's >> > preferred, though >> > it may take longer for users to actually be able to use it. If that >> > approach is preferred >> > and we agree that unblocking users quickly is important, then it might be >> > best >> > to start the process as soon as possible. >> > >> > Best Regards, >> > Yun >> > >> > On Fri, Jul 18, 2025 at 11:29 AM Dmitri Bourlatchkov <di...@apache.org> >> > wrote: >> >> >> >> Sorry, I'm still not clear on the technical details of nightly helm >> >> releases. I imagine any official release will need a vote. >> >> >> >> If the intent of nightly helm releases is to allow end users to use them >> >> in >> >> their deployment environments (not just for testing), I do not think it >> >> would be a good idea due to lack of control of what actually goes into >> >> those artifacts. Users who want to use the very latest helm charts can >> >> always track `main` at the source level. >> >> >> >> In any case, since we obviously have some user demand for a helm chart >> >> fix, >> >> I suppose we could do a 1.0.1 release from the old 1.0.0 release branch by >> >> back-porting just helm chart fixes there and using the same manual process >> >> as for 1.0.0. This will not require adding a separate source bundle for >> >> the >> >> charts (it's part of the normal release already). >> >> >> >> Cheers, >> >> Dmitri. >> >> >> >> On Fri, Jul 18, 2025 at 1:55 PM yun zou <yunzou.colost...@gmail.com> >> >> wrote: >> >> >> >> > This is based on what was mentioned in the first email >> >> > >> >> > > 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? >> >> > >> >> > I think the proposal is to do a non-formal release for Helm Chart with >> >> > the >> >> > current master, and we will need a different place (not the same as the >> >> > current >> >> > helm chart release) to publish this Helm Chart release. >> >> > >> >> > Best Regards, >> >> > Yun >> >> > >> >> > >> >> > >> >> > On Fri, Jul 18, 2025 at 9:03 AM Dmitri Bourlatchkov <di...@apache.org> >> >> > wrote: >> >> > >> >> > > Hi Yun, >> >> > > >> >> > > What do you mean by a "quick nightly release" for helm charts? How >> >> > > will >> >> > it >> >> > > work technically? >> >> > > >> >> > > Thanks, >> >> > > Dmitri. >> >> > > >> >> > > On Fri, Jul 18, 2025 at 11:54 AM yun zou <yunzou.colost...@gmail.com> >> >> > > wrote: >> >> > > >> >> > > > 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 >> >> > > > >> > > > > > > >> >> > > > >> > > > > >> >> > > > >> > >> >> > > > >> >> >> > > > > >> >> > > > >> >> > > >> >> >
