HYPERFLEET-910 - doc: Update release process docs#118
HYPERFLEET-910 - doc: Update release process docs#11886254860 wants to merge 1 commit intoopenshift-hyperfleet:mainfrom
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
WalkthroughThis pull request updates the Hyperfleet release-process document to reflect revised release conventions and workflows. Terminology changes replace "Helm charts" with "OCI Helm charts." Pre-release requirements were simplified to require "Must" feature confirmation and component CHANGELOG verification; several prior checklist items were removed. The Feature Freeze → Stabilization → Code Freeze flow was reworked (removing automatic RC cuts from Feature Freeze, adding Prow job config guidance, and allowing progression to Stabilization without RC tagging). Code Freeze introduces an optional RC-tag decision and a separate RC checklist. GA execution emphasizes OCI Helm chart publication and GitHub Releases aggregation. Stakeholder communication templates and appendix labels were updated. Sequence DiagramssequenceDiagram
participant RM as Release Manager
participant CI as CI / Prow
participant QE as QE Owner
participant GH as GitHub (Releases & Tags)
participant Slack as Stakeholders (Slack)
RM->>Slack: announce Feature Freeze (template)
Slack-->>RM: confirmations
RM->>CI: update ci-operator/config & run `make jobs`
CI->>CI: run presubmit/E2E jobs
RM->>QE: notify stabilization (template)
QE->>CI: request E2E re-run for fixes
CI-->>QE: E2E results
alt RC tagging required
RM->>GH: tag RC (RC1)
GH-->>CI: trigger RC CI jobs
CI-->>RM: RC verification results
else Skip RC -> proceed to GA
RM->>GH: create GA tag
end
RM->>GH: create GitHub Releases (aggregated CHANGELOGs)
RM->>Slack: announce GA (final template)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@hyperfleet/docs/hyperfleet-release-process.md`:
- Line 124: Update the release checklist wording to fix the typos: replace "CI
pipeline ((nightly E2E testing))" with "CI pipeline (nightly E2E testing)" and
correct the typo "testng" to "testing" (these phrases appear in the document
around the checklist items, search for the exact strings "((nightly E2E
testing))" and "testng" to locate the lines to change). Ensure only the wording
is adjusted and formatting/parens remain balanced.
- Line 1222: Edit the release repository requirements sentence in
hyperfleet-release-process.md that references "Release notes for each HyperFleet
Release aggregating component changes (`RELEASE/RELEASE-NOTES-vX.Y.md`)" to
remove the hedging clause “this requirement might also be cancelled” and instead
state it as a mandatory, deterministic requirement (e.g., "Release notes ... are
required for every release until 1.0"), ensuring the line now reads as an
explicit obligation without non-committal language.
- Line 420: Resolve the RC policy inconsistency by making the ad-hoc release
flow and the request template match: either keep ad-hoc releases RC-free or
require an RC for all releases—pick one, then update the two places referenced
(the checklist item text at "Line 420" currently reading "[ ] Tag GA release
directly (RC not required for ad-hoc releases)" and the timeline entry in
"Appendix C, Day 3" that lists "RC build") so they state the chosen policy
verbatim; ensure the checklist, appendix timeline, and any related template
language are consistent and remove or add the RC step accordingly so the ad-hoc
template and checklist no longer conflict.
- Line 1305: The doc lists "GitHub Releases" as a manual MVP step under the
"Manual steps: branching, tagging, OCI Helm chart packaging, GitHub Releases"
line but the GA artifact checklist no longer requires publishing GitHub
Releases; update the release process text to remove "GitHub Releases" from that
manual steps line and adjust any neighboring wording so the Manual steps entry
aligns with the GA artifact workflow (e.g., keep "branching, tagging, OCI Helm
chart packaging" only) and ensure any references or cross-links to the GA
artifact checklist (release process section) consistently reflect that GitHub
Releases are not part of the GA flow.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 34fd6238-d96d-43d7-9c98-335e4b7e0afa
📒 Files selected for processing (1)
hyperfleet/docs/hyperfleet-release-process.md
86254860
force-pushed
the
HYPERFLEET-910-update-release-process-doc
branch
from
dd324d8 to
1caafd0
Compare
There was a problem hiding this comment.
♻️ Duplicate comments (1)
hyperfleet/docs/hyperfleet-release-process.md (1)
421-421:⚠️ Potential issue | 🟡 MinorResolve RC policy inconsistency in ad-hoc release flow.
Line 421 states "RC not required for ad-hoc releases," but the ad-hoc release template (Appendix C, line 1542) includes "E2E testing + GA candidate validation." The term "GA candidate validation" is ambiguous—does it imply an RC build or not?
If ad-hoc releases truly skip RCs, update the template to clearly state "GA validation" or "final E2E validation" instead of "GA candidate validation." If a candidate build is needed, align the checklist and template to acknowledge this requirement consistently.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hyperfleet/docs/hyperfleet-release-process.md` at line 421, Resolve the inconsistency between the ad-hoc release checklist item "Tag GA release directly (RC not required for ad-hoc releases)" and the Appendix C template phrase "E2E testing + GA candidate validation" by choosing one policy and updating both places to match: if ad-hoc releases truly skip RCs, replace "GA candidate validation" in Appendix C with unambiguous wording like "GA validation" or "final E2E validation"; if a candidate build is required, change the checklist item to indicate an RC is required and rename the Appendix C step to "E2E testing + RC (GA candidate) validation" so both the checklist and template reference the same RC requirement.
🧹 Nitpick comments (3)
hyperfleet/docs/hyperfleet-release-process.md (3)
541-557: Documentation scope significantly reduced in favor of component-level ownership.The Documentation Readiness Gate (lines 541-557) and Documentation Finalization (lines 301-306) now focus primarily on release-level artifacts (compatibility matrix, breaking changes, known issues) rather than comprehensive documentation deliverables.
Component-specific documentation (API docs, installation guides, migration guides, troubleshooting) is now delegated to component repositories (line 556, lines 1235-1241). This is a strategic shift from centralized to distributed documentation ownership.
Implication: Ensure component teams understand their documentation responsibilities. If component docs are incomplete, release-level docs may reference missing or outdated content.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hyperfleet/docs/hyperfleet-release-process.md` around lines 541 - 557, The release docs shrink centralized scope and push component documentation responsibility to teams (see "Documentation Readiness Gate" and "Documentation Finalization" sections and the line mentioning component-specific docs), so update the release process text to explicitly state component-owner obligations: add a concise checklist for component teams (API docs, install guides, migration guides, troubleshooting) and a mandatory verification step that release owners must perform (e.g., confirm links or placeholders exist or raise blockers) with escalation instructions if component docs are missing; reference the "Compatibility matrix", "Breaking changes", and "Known issues" artifacts as required release-level inputs and include a short note on where component owners must host and link their docs.
1311-1311: Manual steps list incomplete.Line 1311 lists "branching, tagging, OCI Helm chart packaging, GitHub Releases" but omits "release notes publication in hyperfleet-release repo," which appears in the GA artifact checklist (line 352).
For completeness, consider:
-- Manual steps: branching, tagging, OCI Helm chart packaging, GitHub Releases +- Manual steps: branching, tagging, OCI Helm chart packaging, release notes publication, GitHub Releases🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hyperfleet/docs/hyperfleet-release-process.md` at line 1311, Update the manual steps list entry that currently reads "branching, tagging, OCI Helm chart packaging, GitHub Releases" to also include "release notes publication in hyperfleet-release repo" so it matches the GA artifact checklist; locate the list item in hyperfleet-release-process.md (the section containing the manual steps string) and append the missing step text, ensuring wording aligns with the GA artifact checklist phrase "release notes publication in hyperfleet-release repo".
256-267: Clarify RC optional decision criteria.The RC skip criteria form a complex run-on sentence with multiple conditions:
- "all E2E Prow jobs (tier0, tier1) pass" — terminology "tier0, tier1" is not defined in this document
- "no fixes were merged after the last successful E2E run"
- "no validation requirement for deployment/upgrade scenarios validation" — redundant wording
Consider restructuring as a bulleted checklist for clarity:
**When RC1 can be skipped (all must be true):** - [ ] All E2E Prow jobs on release branches passed during stabilization - [ ] No code changes merged since last successful E2E run - [ ] No additional validation needed for deployment or upgrade scenariosIf "tier0, tier1" are specific job tiers, define them or link to Prow documentation.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@hyperfleet/docs/hyperfleet-release-process.md` around lines 256 - 267, Update the "Release Candidate Tagging (Optional)" section by replacing the run-on RC skip sentence under that header with a clear bulleted checklist titled something like "When RC1 can be skipped (all must be true):" that lists the three distinct conditions: 1) all E2E Prow jobs on release branches passed during stabilization (clarify or link/define the terms "tier0" and "tier1"), 2) no code changes were merged since the last successful E2E run, and 3) no additional validation is required for deployment or upgrade scenarios (remove the redundant word "validation"); ensure the note about MVP releases and RC importance remains below the checklist.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@hyperfleet/docs/hyperfleet-release-process.md`:
- Line 421: Resolve the inconsistency between the ad-hoc release checklist item
"Tag GA release directly (RC not required for ad-hoc releases)" and the Appendix
C template phrase "E2E testing + GA candidate validation" by choosing one policy
and updating both places to match: if ad-hoc releases truly skip RCs, replace
"GA candidate validation" in Appendix C with unambiguous wording like "GA
validation" or "final E2E validation"; if a candidate build is required, change
the checklist item to indicate an RC is required and rename the Appendix C step
to "E2E testing + RC (GA candidate) validation" so both the checklist and
template reference the same RC requirement.
---
Nitpick comments:
In `@hyperfleet/docs/hyperfleet-release-process.md`:
- Around line 541-557: The release docs shrink centralized scope and push
component documentation responsibility to teams (see "Documentation Readiness
Gate" and "Documentation Finalization" sections and the line mentioning
component-specific docs), so update the release process text to explicitly state
component-owner obligations: add a concise checklist for component teams (API
docs, install guides, migration guides, troubleshooting) and a mandatory
verification step that release owners must perform (e.g., confirm links or
placeholders exist or raise blockers) with escalation instructions if component
docs are missing; reference the "Compatibility matrix", "Breaking changes", and
"Known issues" artifacts as required release-level inputs and include a short
note on where component owners must host and link their docs.
- Line 1311: Update the manual steps list entry that currently reads "branching,
tagging, OCI Helm chart packaging, GitHub Releases" to also include "release
notes publication in hyperfleet-release repo" so it matches the GA artifact
checklist; locate the list item in hyperfleet-release-process.md (the section
containing the manual steps string) and append the missing step text, ensuring
wording aligns with the GA artifact checklist phrase "release notes publication
in hyperfleet-release repo".
- Around line 256-267: Update the "Release Candidate Tagging (Optional)" section
by replacing the run-on RC skip sentence under that header with a clear bulleted
checklist titled something like "When RC1 can be skipped (all must be true):"
that lists the three distinct conditions: 1) all E2E Prow jobs on release
branches passed during stabilization (clarify or link/define the terms "tier0"
and "tier1"), 2) no code changes were merged since the last successful E2E run,
and 3) no additional validation is required for deployment or upgrade scenarios
(remove the redundant word "validation"); ensure the note about MVP releases and
RC importance remains below the checklist.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e9fc5813-8872-404d-95d0-25a9a1b1ab54
📒 Files selected for processing (1)
hyperfleet/docs/hyperfleet-release-process.md
1 participant
Summary
Update release process docs aligning with Hyperfleet MVP GA release practice
Test Plan: No need
make test-allpassesmake lintpassesmake test-helm(if applicable)Summary by CodeRabbit