Modernize Helm 4 HIP

hips/hip-0012.md

@@ -9,30 +9,109 @@ status: "draft"
 
 ## Abstract
 
-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.
+It has been over four years since the sucessful Helm 3 release.
+The development of Helm 4 is strongly desired to continue to evolve the Helm ecosystem.
+This HIP documents the requirements (scope of changes) and process for building Helm 4, aiming for an open and productive process.
+
+<!-- scope of changes -->
+Managing the scope of Helm 4 changes is seen as necessary for several reasons: In to produce Helm 4 in a timely fashing (with limited resources).
+As Helm is mature software, to ensure that Helm 4 remains largely feature/functionality compatible with Helm 3.
+And to focus on cleaning up and fix signifcant issues held back by Helm 3 compatiblity guarentees. See motivation for more details.
+
+ <!-- process -->
+Changes are to be managed by being an accompanying (lighter-weight) "Helm 4 proposal", or standard Helm HIP.
+To be approved by Helm maintainers.
+Once approved, enabling the related changes to be approved/merged by a release engineer.
+In order to ease the transtions for users, behavioural changes will need to be accompained by release notes and migration guides, etc.
+
+The Helm 4 development lifecycle will be timeboxed.
+It will be kicked off in X, 2024.
+The process will last not less than six months, and not more than 1 year.
+Preventing a protacted process that prevents the release of Helm 4 in a timely fashion (there will be a Helm 5 of course!)
+
+<!-- criteria for success -->
+The release engineer will determine when Helm 4 is ready to ship. And once shipped, the defined deprecation phase for Helm 3 will begin.
 
 ## Motivation
 
-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, the Helm project drew criticism for not having a well documentated and public Helm 3 development plan.
+So this proposal attempts to spell out a formal process for a sucessful Helm 4 release.
+
+It is desired to scope changes for Helm 4 for two main reasons:
+- Given the limited amount of community resource to enact change(s), it is considered much more important to produce a Helm 4 release which can deliver significant benefits in a moderate timeframe. Than a prolonged process which takes too long to deliver meaningful results.
+- With the significant ecosystem built around Helm: the Helm cli, Chart's, the SDK, etc. It is mandatory that Helm 4 _must_ be largely functionally/feature compatible with Helm 3. In order to maintain coherency in the Helm ecosystem. Breakage of signifcant features/functionmality used by the Helm community, without sufficent migration options/instructions. Will at best delay Helm 4 uptake and incur cost to Helm's users. Or at worst splinter the Helm ecosystem.
+
+Furthermore, 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.
+While it would be great to deliver many new exiciting features with Helm 4, a significantly important requirement for Helm 4 is to refactor Helm's codebase to enable greater capacity for change for Helm in the future.
+
+It is desired to enable the wider Helm community to contribute changes easily and efficently.
+In order to coordinate changes, each significant change or feature will require a sponser who get approval for a Helm 4 proposal or HIP, and work with the release engineer to get changes merged.
+This elease engineer and managed b
+
+<!--
+A proposal can either be a standard HIP, or a lighter weight Helm 4 change proposal (similar to Helm 3 proposals: [hips/archives/helm/helm-v3](https://github.com/helm/community/tree/main/hips/archives/helm/helm-v3)). Details follow in the "TBD" section.
+-->
 
 ## Rationale
 
 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.
+
+This document is intended to address these criticisms and present a reasonable plan for timely delivery of a valuable Helm 4 release to the community.
 It describes the process in detail, providing both a method for us to follow and a point of reference for community members to read.
 
+The process based on the following ideas:
+- Requiring changes to be documented (Helm 4 proposals, or standard HIPs) both allows Helm communitity members to review changes, and allow Helm maintainers to provide oversight on the functional and architectual implementation of the given change. Ensuring changes are in good standing with respect to this HIP.
+Finally, documented changes should allow contributors to independently execute changes to the agreed proposal in coordination with the release engineer.
+
+- Requiring a timeboxed development effort intends to both promote focus on the most valuable changes that the community/maintainers can deliver within a reasonable timeframe, and avoid an "open ended" development cycle that might drag on and/or fizzle out.
+Ideally the majority of changes will be proposed and agree upon early in the development cycle (the planning phase), but changes to this initial scope can be ammended during the course of the development lifecycle. So long as they can fit within the agreed upon timeframe. Making amending the scope an exlicit requirement seeks to ensure that any changes are well thought out.
+For forther changes that don't make it into Helm 4, there will be a Helm 5 of course!
+
+
 ## Specification
 
+There will be an active Helm 4 planning then development phases, followed by an alpha period, a beta period, and a release candidate period.
+
+Attempt to consider different parts of the Helm ecosystem seperately. As different parts of the ecosystem has focus from different users. These largely are:
+- Charts, including chart authors and consumers (users)
+- Helm cli users
+- SDK users
+
+- every non-compatible change must have a migration docs
+- behavioural changes that negatively affect a significant number of users (without a reasonable migration) can't be allowed
+- charts that can be deployed with Helm 3 must be deployable by Helm 4. And similarly, any release created by Helm 3 much be managable by Helm 4 and vice versa.
+
+### Change suitability
+
+The Helm ecosystem is large and encompasses the Helm CLI as well as the SDK and Charts. The Helm project must be judicious in how it delivers changes without significant adverse impact to the ecosystem.
+
+So while Helm 4 need not be semantically backwards compatible with Helm 3, it must not cause significant breakage through the
+
+With migration options and paths clearly present and documented for Helm 3 users to update to Helm 4.
+
+### Change proposals
+
+#### Helm 4 proposals
+
+A "Helm 4 proposal" is simply a lightweight version of the Helm HIP process. Intended to make it simple to specify small changes for Helm 4. See appendix for a template of the proposal
+
+#### HIPs
+
+Standard Helm HIP, marked as suitable for Helm 4
+
+### Architecture Oversight
+
+In order to ensure Helm 4 changes are aligned to this HIP, Helm core mantainers will review proposals. Either in the form of Helm 4 specific proposals (intended to be a lighter-weight process to HIPs). Or HIPs, which deemed to be suitable for Helm 4 implementation.
+
+When a Helm 4 proposal is deemed suitable, it will be marked as implementable in the hips/helm-v4 [hips/helm/helm-v4](https://github.com/helm/community/tree/main/hips/helm/helm-v4) directory.
+
+### Compatbility
+
+As Helm is mature software, with a a significant ecosystem built around the cli tooling, charts, the SDK, etc. Even with Helm 4 being a major version release which does not need to adhere to HIP TBD compatibility guarentees, it needs to be ensured that while Helm 4 need not remain semantically compatible with Helm 3, it must remain largely feature/functionality compatible with Helm 3.
+
+
 ### The Release Engineer
 
 A single individual will oversee the planning and development phases of Helm 4.
@@ -44,7 +123,7 @@ The person will have the following responsibilities:
 - 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)
+- After the release, the release engineer 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)
 
 #### Determining Who Will Be Release Engineer
 
@@ -156,8 +235,8 @@ 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:
+Multiple release engineers were also considered.
+However, two things suggest multiple release engineers would not be appropriate:
 
 1. The desire to have a single authority for architectural integrity and resolution
 2. The simple fact that there are not enough Helm core maintainers to justify having a committee