Hi Yufei, Thanks for reviving this discussion! I am +1 on all your suggestions.
Thanks, Alex On Wed, Jun 25, 2025 at 10:51 PM Yufei Gu <flyrain...@gmail.com> wrote: > > Thanks Dmitri for raising this. Thanks all for the discussion. Can we > conclude this thread? Here are some points we discussed(1, 2, 3) + my > suggestion for versioning(4,5): > > 1. Publish the Helm Chart along with Polaris src/bin release. > 2. Publish the Helm Chart to dist.apache.org > 3. Using the same version for Helm Chart and docker image version > 4. Use the Polaris release version(e.g., 1.0.0-incubating) for appVersion, > it doesn't quite matter as it is a free form hint pointed out by Alex. > 5. Use the Polaris release version(e.g., 1.0.0-incubating) for the docker > image tag(the `tag` field in values.yaml), so that there is no > compatibility issue when users revert to a historical version of the Helm > Chart, more details are here, > https://github.com/apache/polaris/pull/1944/files#r2167585393. > > Yufei > > > On Mon, Feb 3, 2025 at 9:32 PM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > > +1 to release Helm charts as part of a Polaris release (with other > > artifacts). > > > > If we can create a repo for helm charts, most of the ASF projects providing > > helm charts do that on their website and/or main repo via dist.apache.org > > (that is used also for download.apache.org and archive.apache.org). > > > > I think we should use dist.apache.org for helm charts releases. > > > > Regards > > JB > > > > Le ven. 31 janv. 2025 à 11:04, Alex Dutra <alex.du...@dremio.com.invalid> > > a > > écrit : > > > > > Hi again, > > > > > > We also need to discuss hosting Helm charts. We cannot release a Helm > > chart > > > if there is no repository available to host our charts. > > > > > > There are several ways of achieving this, but one simple solution would > > be > > > to host our charts on a separate GitHub repository. This alone can be > > > enough for users to be able to "helm pull" our charts. Optionally, we can > > > also reference the chart on https://artifacthub.io/ to reach an even > > > broader audience. > > > > > > I don't know, however, what it takes for the ASF to give us a separate > > > GitHub repo. We may want to explore what other Apache projects are doing. > > > AirFlow for example seems to have transformed their website, > > > airflow.apache.org, into a Helm repo: > > > > > > - The index.yaml file is available at the root of the website: > > > https://airflow.apache.org/index.yaml – this means, users can add the > > > repo with "helm repo add airflow https://airflow.apache.org"; – which > > > looks very nice. > > > - The chart URLs in the index.yaml file point to downloads.apache.org > > > or > > > archive.apache.org, indicating that they are probably pushing the > > chart > > > packages to ASF servers. > > > - The documentation is here: > > > https://airflow.apache.org/docs/helm-chart/stable/index.html. > > > > > > Also worth noticing: AirFlow seems to be using separate versioning > > schemes > > > for the chart and the app, while still hosting the chart and the app > > > together: > > > https://github.com/apache/airflow/blob/2.10.4/chart/Chart.yaml#L22-L23. > > > > > > Anyways, I'm curious to hear what others think about this topic as well. > > > > > > Thanks, > > > > > > Alex > > > > > > On Fri, Jan 31, 2025 at 10:42 AM Alex Dutra <alex.du...@dremio.com> > > wrote: > > > > > > > Hi, > > > > > > > > Let me try to shed some context. Helm chart versioning was designed to > > be > > > > independent of application versioning. This is why the Chart.yaml > > > > descriptor provides two fields: > > > > > > > > - "version" is the Helm chart version, and follows semver strictly > > > > - "appVersion" is the target application version (optional, free > > form) > > > > > > > > And even if this seems to tie a Helm chart version X to an application > > > > version N, "appVersion" is just a hint. A Helm chart version X is > > capable > > > > of deploying target application versions in a range of M to N – because > > > > ultimately what counts is the Docker images being deployed, and these > > can > > > > have any version as long as they are compatible. The range boundaries > > are > > > > dictated solely by changes in the application configuration interface > > > that > > > > would make the Helm chart unsuitable for use with it: e.g. if the Helm > > > > chart configures the application with environment variable FOO, but all > > > of > > > > a sudden the variable is renamed to BAR in version N, then we have an > > > > incompatibility between chart X and app N. > > > > > > > > So what Dmitri proposes makes total sense generally speaking. > > > > > > > > It is true though, that this flexibility may introduce some confusion > > for > > > > users. Many users tend to consider that the Helm chart version X must > > > equal > > > > the application version N, and they even install a new chart every time > > > > they upgrade their deployments. That's not required per se, but is > > often > > > > seen in the field: both the Helm chart and the docker images get > > upgraded > > > > simultaneously. > > > > > > > > In any case, we also need to take into account some practicalities: the > > > > Helm chart currently lives in the same repo as Polaris itself. This may > > > or > > > > may not be the best option, but it is what we have today. Because of > > > that, > > > > it's a lot easier for us if we consider that releasing Polaris entails > > > > releasing the Helm chart as well. > > > > > > > > In the light of this, I am more in favor of releasing the Helm chart > > > along > > > > with every binary release, using the same versioning scheme for both > > the > > > > Docker images, the distribution binaries, and the Helm chart. Granted, > > > more > > > > often than not, the Helm chart will be released as X+1, with no actual > > > > changes in it; IOW, chart version X would be identical to X+1. But if > > > > that's a problem, I'd argue that the Helm chart should be moved to a > > > > separate repo. > > > > > > > > Hope that makes sense, > > > > > > > > Alex > > > > > > > > On Thu, Jan 30, 2025 at 8:01 PM Eric Maynard <eric.w.mayn...@gmail.com > > > > > > > wrote: > > > > > > > >> That seems like it could confuse users to me. The docs will refer to > > > >> feature X being in version Y of the application — how do I connect > > that > > > to > > > >> a helm chart? Or if I want to go read the source code that’s connected > > > to > > > >> the helm chart I’m running, where do I find that mapping? > > > >> > > > >> Couldn’t we just cut a patch version of the source and do a release > > > >> (binary > > > >> + helm chart) so that there’s always a clear coupling? > > > >> > > > >> On Thu, Jan 30, 2025 at 10:44 AM Dmitri Bourlatchkov < > > di...@apache.org> > > > >> wrote: > > > >> > > > >> > Hi All, > > > >> > > > > >> > PR 912 [1] prompted this discussion. > > > >> > > > > >> > I believe it is valuable to release helm charts separately from the > > > main > > > >> > source / binary bundle primarily because the lifecycle of the charts > > > is > > > >> > different from java code and often requires changes that are not > > > >> connected > > > >> > to service implementations. > > > >> > > > > >> > I'd like to propose: > > > >> > > > > >> > * Each binary java release to have a matching Helm chart release > > with > > > >> > possibly a different version. > > > >> > > > > >> > * Allow independent helm chart releases. > > > >> > > > > >> > * Source releases (e.g. 0.9) do not have to be connected to any > > > >> particular > > > >> > helm chart release. > > > >> > > > > >> > Thoughts? > > > >> > > > > >> > [1] https://github.com/apache/polaris/pull/912 > > > >> > > > > >> > > > > > > > > >
