Thanks for the summary, Yufei!
+1 to all points (1 - 5).
Re: 5: just to clarify - reverting to an old helm chart version with this
version / tag scheme will mean reverting to an old Poalris binaries
version, which is technically a downgrade. I do not think we discussed our
approach to downgrades,
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 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
> sugge
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 v
+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).
>
> 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 a
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
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
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
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
