F44 Change Proposal: Helm4 [SelfContained]

[mikelo2 (Mikel Olasagasti)]

Helm4

Wiki

Announced

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

Helm 4 has been released upstream with intentional backwards-incompatible changes relative to Helm 3. To ensure a smooth transition for Fedora and EPEL users, this Change introduces Helm 4 as the default helm package in Fedora Rawhide, while providing a parallel-installable helm3 package for users and tooling that still rely on Helm 3.

Helm 3 will continue to be available and maintained as helm3 in Fedora and EPEL, while the helm package will track the latest major release (Helm 4 going forward).

Owner

• Name: [[User:mikelo2| Mikel Olasagasti]]
• Email: mikel@olasagasti.info

Detailed Description

Upstream Helm 4 introduces breaking changes in CLI behavior, chart handling, and release workflow compatibility compared to Helm 3. Many users in CI/CD, Kubernetes automation, and cluster operators still depend on Helm 3’s behavior and may not be immediately able to migrate.

Upstream has committed to maintaining Helm 3 with bug fixes until 2026-07-08 and with security fixes until 2026-11-11. To provide Fedora users with a stable transition period, both versions will be shipped in parallel until upstream support ends.

Package	Version	Binary name	Notes
helm	Helm 4	helm	Default package (tracks latest major upstream)
helm3	Helm 3	helm3	Maintained in Fedora until upstream support ends

=== Planned retirement schedule ===
Helm 3 will remain available in Fedora until upstream ends security support.

Given current Fedora release cadence, this means:

• helm3 will continue to be shipped through Fedora 44.
• Once Fedora 44 is branched from Rawhide (expected mid-2026), helm3 may be retired from Rawhide and will not appear in Fedora 45+.

Feedback

Benefit to Fedora

• Keeps Fedora up to date with the latest upstream technology.
• Preserves backward compatibility via helm3.
• Reduces upgrade friction for cluster operators and CI/CD automation.
• Allows gradual migration and testing of Helm 4.
• Aligns Fedora with Kubernetes ecosystem direction.

Scope

• Proposal owner (packager):
  ** Create helm3 spec based on existing Helm 3 sources.
  ** Update existing helm spec to Helm 4.
  ** Ensure parallel installability (no conflicting binaries/files).
  ** Provide clear documentation in package descriptions.
• Release engineering:
  ** Normal review and acceptance of Change.
  ** No mass rebuild required.
• Policies and guidelines: No
  ** This is a Self-Contained Change.
  ** No system-wide impact beyond the Helm ecosystem.

Upgrade/compatibility impact

• Users upgrading Fedora may find helm now provides Helm 4.
• Scripts and automation depending on Helm 3 must explicitly install helm3.
  The intent is not to break existing Helm 3 workflows, but to allow Fedora users to adopt Helm 4 when ready.

Early Testing (Optional)

Do you require ‘QA Blueprint’ support? No

How To Test

dnf install helm
helm version  # should report Helm 4
dnf install helm3
helm3 version # should report Helm 3

Both versions must be installable simultaneously and functional without file conflicts.

User Experience

Users get the latest major upstream version by default. Those requiring Helm 3 can run:

sudo dnf install helm3


Dendencies 


Contingency Plan 

• Contingency mechanism: Not a System-Wide Change.
  ** If packaging or testing of Helm 4 is not completed in time, the helm package will remain on Helm 3 and the Helm 4 update will be deferred to the next Fedora release cycle.
  ** If creation of the helm3 compatibility package is delayed, helm must remain on Helm 3 to avoid breaking user workflows and expectations.
  ** No forced migration, no Obsoletes/Provides, and no package replacement will occur under contingency.(What to do? Who will do it?) N/A (not a System Wide Change)

Documentation

N/A (not a System Wide Change)

Release Notes

Last edited by @alking 2025-11-26T15:08:46Z

Last edited by @alking 2025-11-26T15:08:46Z

[system]

How do you feel about the proposal as written?

• Strongly in favor
• In favor, with reservations
• Neutral
• Opposed, but could be convinced
• Strongly opposed

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

[zbyszek (Zbigniew Jędrzejewski-Szmek)]

If the package name is changed, upgrading users will end up with the new version. They’d need to dnf install helm3 explicitly to get version 3. Is this intended? (If not, maybe both new helm and helm3 should have Obsoletes: helm < ... to tell dnf to install both packages on upgrade?)

[mikelo2 (Mikel Olasagasti)]

It’s either that way, intended, or creating helm4 and helm3 packages and have a Provides: helm. I can’t figure out better options.

With this second option users would explicitly need to install helm4 during F44 cycle or wait until F45 retires helm3, and both packages would need to be introduced in F43 to ensure upgrade path.

I think Fedora should push to newer versions in upgrades while having helm3 as an alternative and document this in the release notes .

[zbyszek (Zbigniew Jędrzejewski-Szmek)]

According to the packaging guidelines, the “current” version should be without suffix, and any compat versions should have the version suffix. So the naming of helm and helm3 is the correct one. No discussion about this.

My question is narrower: should users who upgrade and had old helm installed, get just the new helm package or both helm and helm3?

[mikelo2 (Mikel Olasagasti)]

Current plan would be only helm, not both.

[alking (Allison King)]

This change proposal has now been submitted to FESCo with ticket #3522 for voting.

To find out more, please visit our Changes Policy documentation.

[sgallagh (Stephen Gallagher)]

Well, there’s one other option that wasn’t considered: introduce both helm3 and helm4 into Fedora 43 and Fedora 44:

helm3 in Fedora 43:

Provides: helm = %{version}-%{release}
Obsoletes: helm < 3.19.0-4

helm3 in Fedora 44:

Obsoletes: helm < 3.19.0-4

helm4 in Fedora 43 (optional) includes no special Provides or Obsoletes.

helm4 in Fedora 44:

Provides: helm = %{version}-%{release}

Then, the result is: anyone who has helm today would have it replaced by helm3. Anyone who wants to move to helm4 in Fedora 43 could explicitly install the helm4 package. Anyone who just runs dnf install helm would get helm3 on Fedora 43 or helm4 on Fedora 44.

The effect here is that anyone using helm3 today won’t be automatically moved to helm4, but anyone installing it fresh in F44 will get the new version.

(This assumes that both packages are co-installable. If they are not, things get more complicated.)

[gotmax23 (Maxwell G)]

In the current proposal, helm3 would provide /usr/bin/helm3, not /usr/bin/helm, to make the packages parallel installable, so having helm3 replace helm on updates would cause users to end up with no helm command at all. That would likely be more confusing than getting package major version updates when updating to a new Fedora major release which is a standard occurrence.

[sgallagh (Stephen Gallagher)]

The alternatives system exists for situations like this: we can make helm4 be the default provider of /usr/bin/helm in Fedora 43, but if they upgraded from Fedora 42, they’d be migrated to helm3, which would then satisfy alternatives as the default, thus keeping them on that compatible release.