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