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é <j...@nanthrax.net> 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 > > > > >> > > > > > > > > > > >> > > > > > > > > >> > > > > > >> > > > > > > > > > > > > > > >
