Modernize Helm 4 HIP #346
Modernize Helm 4 HIP #346
Conversation
|
@gjenkins8 just want to say publicly I really like how this PR is going. Not reviewing yet because it's still in progress. But I agree that updating this excellent earlier proposal will help lay the groundwork for smoother contribution and delivery for the Helm 4 development process. Also – for transparency – this PR addresses the Helm 4 process side of ideas discussed in weekly Helm 4 roadmap meetings. The meetings are documented here: https://docs.google.com/document/d/1WJ3K96fJeldKHoKhejWHDvCOTddEvY-RCtQBUaZ57FM/edit |
| years is ambitious. | ||
| So this proposal attempts to merely spell out a formal process for Helm 4. | ||
| Helm 3 has been greatly sucessful. | ||
| And Helm has built a significant ecosystem of the Helm tooling (CLI), charts, chart repositories and repos, the SDK, plugins, etc. |
There was a problem hiding this comment.
This sentence doesn't read quite right. Maybe something like....
And Helm has built a significant ecosystem around the Helm client (CLI), charts, chart repositories, SDK, plugins, etc.
| The Helm project needs to continue to evolve. | ||
| Kubernetes itself has continued to grow and change. | ||
| And Helm needs to continue to evolve as well to continue to provide value to the Helm community. |
There was a problem hiding this comment.
Evolve feels like an ill defined word, here. What about something like...
As Kubernetes continues to grow and change, Helm needs to adapt to those changes while continuing to grow new features and functionality to support its mission around package management for Kubernetes.
| And Helm needs to continue to evolve as well to continue to provide value to the Helm community. | ||
|
|
||
| However, Helm has also accumulated debt. | ||
| And Helm 3 today has the significant issue that many (good) changes are overly difficult to implement due to compatibility concerns: either breakage of behavioural functionality or API incompatibility. |
There was a problem hiding this comment.
This might be a good place to mention SemVer and how breaking and behavioral changes cannot happen without a major version change.
| If possible, the kick-off meeting will be held at KubeCon North America in 2024, | ||
| and the resources of CNCF will be utilized for advertising this meeting and its purposes. |
There was a problem hiding this comment.
In the past, we have had specific meeting space at kubecons outside of session. This time we are doing booth time, contribfest time, and a session. We don't have the space reserved or, I think, have the bandwidth for a separate kickoff meeting. How would you see this unfolding?
| ### Prerequisites | ||
| Before Helm can start the development of Helm v4 there are some things the Helm organization needs to have in order. | ||
| These include: | ||
|
|
||
| - Active maintainers who will take the time to review changes. | ||
| Helm has been in an unoffical "maintenance mode" for some time where changes have slowed down and the project needs the people capable of driving a Helm 4. | ||
| - Direction on what is in and out of scope for Helm 4. | ||
| It’s important to be able to know what to say “yes” to and what to say “no” to with reasons for both. | ||
| - A timeline for the development of Helm 4. | ||
| A timeline sets expectations for the time of development. | ||
| If the time for development is open-ended then development could end up in a perl 6 development cycle and just take forever. | ||
| At some point development needs to stop. | ||
|
|
||
| This HIP aims to define sucess criteria for these. |
There was a problem hiding this comment.
Should we take out this section? I ask for a few reasons...
- "maintenance mode" can send a bit of the wrong impression because Helm has been active, even if the activity has been lower. This includes new features. I asked AI what "maintenance mode" means and this is what I got...
"Maintenance mode" in reference to an open source project typically means that the project is no longer actively developed with new features or major changes. Instead, the focus is on maintaining the existing codebase.
- We don't have a full list of what's in scope so this pre-requisite isn't achieved and won't likely ever be.
| 1. Earliest that engineering can begin: Nov. 2024 | ||
| 1. Expected release of Helm v4.0.0 will be planned for the week before KubeCon/CloudNativeCon North America 2025 (expected November 2025) | ||
|
|
||
| Prior to the stable release there will be 4-6 weeks of release candidates for the public to test. The time period will be determined by the testing and state of trust in the code leading up to the release candidate window. |
There was a problem hiding this comment.
I wonder if this should be synced differently with the release preparation section. That covers betas, RCs, etc. Thoughts?
|
|
||
| ``` | ||
| TBD | ||
| ``` |
There was a problem hiding this comment.
How should this be different from a HIP?
No description provided.