> > 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.
+1 on the same version for docker image, the distribution binaries and the Helm chart. I didn't get the X+1 part with no change. Why do we need X+1 if X is there for the Helm chart? Yufei On Fri, Jan 31, 2025 at 1:42 AM Alex Dutra <alex.du...@dremio.com.invalid> 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 > > > > > >
