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