| hip | title | authors | created | type | status | |
|---|---|---|---|---|---|---|
0012 |
Helm 4 Development Process |
|
2021-04-02 |
process |
draft |
The Helm 4 development lifecycle will be managed by a release engineer. It will be kicked off in October, 2021. The process will last not less than six months. There will be an active development phase, followed by an alpha period, a beta period, and a release candidate period. The release manager will determine when Helm 4 is ready to ship.
We do not currently have a documented process for kickstarting new major Helm versions. During the Helm 3 process, we drew criticism for not having such documentation. However, a "generalized" process that can span multiple major versions over multiple years is ambitious. So this proposal attempts to merely spell out a formal process for Helm 4.
During the Helm 3 process, Helm core maintainers received criticism that the development process was not described publicly enough. Further criticism was that it was unclear who was "running the show" and how they were making decisions. Finally, we were criticized for not explaining the criteria we were using for determining when Helm 3 was complete. This document is intended to address these criticisms. It describes the process in detail, providing both a method for us to follow and a point of reference for community members to read.
A single individual will oversee the planning and development phases of Helm 4. This person will be the Release Engineer. The person will have the following responsibilities:
- Lead the kick-off meeting
- Define the process for including features
- Determine the timelines for development
- Make the determination of when the project has indeed reached a milestone
- Name and oversee releases
- After the release, the release manager will determine what the "intent" of a Helm behavior was (which informs determining whether an incoming breaking change is a feature or a bug fix)
The release engineer must be a core maintainer on the github.com/helm/helm project.
The engineer must not be in danger of losing core maintainer-ship due to inactivity.
Anyone can nominate a core maintainer to become the release engineer (self-nominations are encouraged).
Any nominee must agree to the nomination.
The Helm project maintainers will determine which of the nominated maintainers shall be the release engineer.
In the event that a release engineer cannot perform the duties required, the Helm project maintainers may choose a replacement.
There will be three phases to Helm 4 development:
- Planning
- Feature development
- Release preparation
The timeline will be approximately:
- Naming of a Release Engineer: Sept. 2021
- Kick-off meeting: Oct. 2021
- Earliest that engineering can begin: Jan. 2022
- Earliest that a release could possibly be: May, 2022
More likely, the release will be late 2022 to midyear 2023.
This phase begins when the release engineer is named. The release engineer shall schedule a kick-off meeting in which all Helm maintainers (from any Helm org project) will be invited to participate. Beyond these participants, the release engineer may determine who else will be included, and may determine the meeting to be public. The kick-off meeting will open the floor to feature ideas and changes, with preference toward ideas already documented as HIPs.
This process will continue as long as the release engineer determines necessary, but not less than three months. This minimum time frame is intended to give ample time for the community to provide input.
All features and breaking changes MUST be described in a HIP, and that HIP must pass the usual process. This provides three benefits:
- All changes are documented
- All changes have had a period of scrutiny prior to the PR being written
- There is a clear record of alternative considerations
Things that are deemed by core maintainers to be "bug fixes" (and not changes or features) do not need HIPs.
The outcome of the planning cycle is a clear record of approved HIPs describing Helm 4 features. This must be done prior to development beginning. This list of HIPs will serve as the "blueprint" for working on Helm 4.
During this phase, the features and changes agreed upon during planning will be implemented in a development branch of Helm. Breaking changes are explicitly allowed, as are experimental features that may be removed prior to final release. PR approval will follow the usual process, but with the exception that any PR that is not part of the existing plan MUST be approved by the Release Engineer.
This phase culminates in Alpha releases, in which features may still be added and breaking changes may be made as determined appropriate by the release engineer.
During this last phase, no new features will be added except as determined by the release engineer to be critical. Emphasis will be on bug fixes, documentation improvement, security audits and fixes, and preparation of the ecosystem (e.g. charts changed). All Beta and RC releases are done as part of this phase.
This phase will terminate, and Helm 4.0.0 development will be deemed complete, upon the release of Helm 4.0.0.
However, this phase must not be less than three months in order to give the broader ecosystem ample time to test and provide feedback.
During the course of development, it may turn out that there is not sufficient reason to continue development on Helm 4. For example, there may not be enough feature HIPs to justify releasing, or the HIPs may not achieve enough sponsorship or support from Helm project maintainers.
In this case, the Helm maintainers may hold a "circuit breaker" vote to halt Helm 4 development until such a time when it is warranted.
The process for halting Helm 4 development will be a simple majority vote by the Helm project maintainers.
This section outlines how we will support Helm 3 during Helm 4 development. However, the Release Engineer is at liberty to refine this section in the name of maintaining the best experience for Helm users.
During the "Feature Development" cycle of Helm 4, Helm 3 will continue to receive security, bug, and minor feature patches.
During the Alpha, Beta, and RC phases of Helm 4, Helm 3 will not receive any feature patches. This is to prevent Helm 3 from introducing features that should be in Helm 4, but during a window when Helm 4's features are frozen.
Helm 3 will receive 6 months of bug fixes and one year of security fixes from the day that Helm 4 is released.
Nothing in this document is contrary to our existing process for decision making. Note that this does not change the PR review process or the HIP process. It assumes that both of those processes will remain the same.
The contents of this HIP will be discussed in the public Helm Dev meeting, which is recorded. If possible, the kick-off meeting will be held at KubeCon North America in 2021, and the resources of CNCF will be utilized for advertising this meeting and its purposes.
During all stages of Helm 4 development, the Release Engineer will ensure that an update on progress is given at no fewer than two Helm public dev calls each month.
Helm 3 was largely developed along an informal version of the above model. However, we were criticized for not documenting the process or explaining how we were going to follow the process. This proposal provides an alternative to an "informal process" that would draw similar ire.
Multiple release managers was also considered. However, two things suggest multiple release managers would not be appropriate:
- The desire to have a single authority for architectural integrity and resolution
- The simple fact that there are not enough Helm core maintainers to justify having a committee
We considered allowing a non-core maintainer be a release engineer, but rejected for the following reasons:
- A release engineer needs detailed information about Helm's design, intents, and implementation. Our only way to ensure this is via maintainer-ship.
- A non-core maintainer is not bound by the core maintainer process, and this would introduce tension and exceptionalism.
It has been suggested that Microsoft should lead the development process, as it was MS engineers who started Helm, and MS engineers are the most frequent contributors to Helm. We have decided there is no reason why any other core maintainer should be ruled out in virtue of their chosen employment. We also believe such a restriction runs contrary to CNCF's intentions.
We considered allowing any Helm maintainer from any project to be the release engineer for Helm. However, we determined that the special knowledge of the Helm core codebase is requisite for successfully fulfilling this role, especially as pertains to the technical decision making required in this role. We consider the release engineer to be more of an architect's role than a project manager's.
We considered restricting release engineer to just org maintainers. However, it is a stated goal of the org maintainers that they be focused on the organizational (not technical) aspects of the project. Release engineering is beyond their charter.
We considered not requiring HIPs for features and changes during the Helm 4 process. In the past, we have done without. But also, in the past we have had substantial pushback from the community that major changes were not discussed and were pushed through. Furthermore, there is an almost complete absence of documentation for why decisions were made in Helm 2. And in Helm 3, the documentation is limited to only a few draft documents. Therefore, HIPs will provide a framework for discussion as well as a documented decision making process. While some may complain that this is undue overhead, we believe the benefits far outweigh the burden.
We considered removing the mandatory minimum times for planning and for release preparation. However, a major version transition must be done with care, especially on a project with as much impact as Helm's. It is in the community's best interest for the developers to move at a deliberate pace with public timeframes.
- The Helm org's governance documents
- The Helm 3 planning documents