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