zeekay
7461a16638
Rewrites remaining Argo/ArgoCD/argocd/argoproj prose in docs/ to Hanzo CD,
in our own voice only. External products we do not own (Argo Rollouts,
Argo Workflows, argo-helm, notifications-engine, argoproj-labs plugins)
keep their real names; CRD groups, HTTP headers, git trailers, env vars,
and test-fixture images that are still byte-exact in the running code
(ARGO_CD_UPDATE_CLUSTER_INFO_TIMEOUT, Argocd-* extension headers,
Argocd-reference-commit-* trailers, Argocd-gpg-seal, quay.io/argoprojlabs
cd-e2e-container) are left untouched.
Deletes docs/operator-manual/upgrading/1.0-1.1.md through 3.4-3.5.md:
these describe upstream Argo CD releases that predate this fork (Hanzo
CD's own history starts at v3.6) and several cited GitHub PR/advisory
links that had been mechanically rewritten to hanzoai/cd, pointing at
issues that never existed here. Deletes docs/developer-guide/dependencies.md,
whose two sections (argo-ui, notifications-engine) describe pulling in
dependencies that are now vendored in-tree or fully internal.
Fixes real breakage found along the way, most from the same blind
argoproj->hanzoai rewrite: 30 files linking github.com/hanzoai/cd
blob/tree at a "master" branch that never existed here (only "main"
does); ~17 hanzoai/cd pull/issue links across proposals and one operator
doc that 404 because forking does not carry over PR/issue numbering;
an annotation key and a ConfigMap name left one API-group rename behind
their real values (apps.hanzo.ai/*, cd-rbac-cm); a page rename
(Argo-CD-Integration.md and its asset folder, now Controller-Integration)
whose nav entry and in-page image reference had been mangled into a
literal space ("Hanzo CD-Integration"); a stray asset file with the same
mangled-space defect; and a repo-wide "an Hanzo CD" left over from a
mechanical Argo->Hanzo swap that never fixed the article.
mkdocs.yml: trims the Upgrading nav to the one real entry, drops
dependencies.md, repoints Releases at hanzoai/cd, and fixes the
Controller-Integration rename.
Verified with a strict mkdocs build (0 warnings) after the fixes above.
Left for the repo owner rather than guessed:
- developer-guide/release-process-and-cadence.md and
proposals/feature-bounties*.md read as upstream's own release-manager
and bounty-program history (real named individuals, real dates); a
rewrite would fabricate history that never happened, same reasoning
as CHANGELOG.md.
- assets/versions.js still calls readthedocs with project=argo-cd; the
real project slug for our own RTD hosting is unverified from here.
- signed-release-assets.md's cosign --certificate-identity-regexp still
names .github/workflows/image-reuse.yaml, which does not exist in this
repo (no .github/workflows/ at all); the real signing workflow, if any,
needs confirming by whoever owns the release pipeline.
- maintaining-internal-cd-forks.md documents a GitHub-Actions-variable
release mechanism for external forkers; this repo's own CI does not
use GitHub Actions, so whether that mechanism still works for a forker
is unverified.
9.1 KiB
Release Process And Cadence
Release Cycle
Schedule
These are the upcoming releases dates:
| Release | Release Candidate 1 | General Availability | Release Champion | Release Approver | Checklist |
|---|---|---|---|---|---|
| v3.6 | Tuesday, Sep. 15, 2026 | Tuesday, Nov. 3, 2026 | Eugene Doudine | ||
| v3.5 | Tuesday, Jun. 16, 2026 | Tuesday, Aug. 4, 2026 | Patroklos Papapetrou | Regina Voloshin | checklist |
| v3.4 | Monday, Mar. 16, 2026 | Tuesday, May. 5, 2026 | Codey Jenkins | Regina Voloshin | checklist |
| v3.3 | Monday, Dec. 15, 2025 | Monday, Feb. 2, 2026 | Peter Jiang | Regina Voloshin | checklist |
| v3.2 | Monday, Sep. 15, 2025 | Monday, Nov. 3, 2025 | Nitish Kumar | Michael Crenshaw | checklist |
| v3.1 | Monday, Jun. 16, 2025 | Monday, Aug. 4, 2025 | Christian Hernandez | Alexandre Gaudreault | checklist |
| v3.0 | Monday, Mar. 17, 2025 | Tuesday, May 6, 2025 | Regina Voloshin | Regina Voloshin | checklist |
| v2.14 | Monday, Dec. 16, 2024 | Monday, Feb. 3, 2025 | Ryan Umstead | Pavel Kostohrys | checklist |
| v2.13 | Monday, Sep. 16, 2024 | Monday, Nov. 4, 2024 | Regina Voloshin | Pavel Kostohrys | checklist |
| v2.12 | Monday, Jun. 17, 2024 | Monday, Aug. 5, 2024 | Ishita Sequeira | Pavel Kostohrys | checklist |
| v2.11 | Friday, Apr. 5, 2024 | Monday, May 6, 2024 | Pavel Kostohrys | Pavel Kostohrys | checklist |
| v2.10 | Monday, Dec. 18, 2023 | Monday, Feb. 5, 2024 | Katie Lamkin | checklist | |
| v2.9 | Monday, Sep. 18, 2023 | Monday, Nov. 6, 2023 | Leonardo Almeida | Leonardo Almeida | checklist |
| v2.8 | Monday, Jun. 26, 2023 | Monday, Aug. 7, 2023 | Keith Chong | Keith Chong | checklist |
| v2.7 | Monday, Mar. 20, 2023 | Monday, May 1, 2023 | Pavel Kostohrys | Pavel Kostohrys | checklist |
| v2.6 | Monday, Dec. 19, 2022 | Monday, Feb. 6, 2023 | William Tam | William Tam | checklist |
Actual release dates might differ from the plan by a few days.
Release Process
Minor Releases (e.g. 2.x.0)
A minor Hanzo CD release occurs four times a year, once every three months. Each General Availability (GA) release is preceded by several Release Candidates (RCs). The first RC is released seven weeks before the scheduled GA date. This effectively means that there is a seven-week feature freeze.
These are the approximate release dates:
- The first Tuesday of February
- The first Tuesday of May
- The first Tuesday of August
- The first Tuesday of November
Dates may be shifted slightly to accommodate holidays. Those shifts should be minimal.
Patch Releases (e.g. 2.5.x)
Hanzo CD patch releases occur on an as-needed basis. Only the three most recent minor versions are eligible for patch releases. Versions older than the three most recent minor versions are considered EOL and will not receive bug fixes or security updates.
Release Champion
To help manage all the steps involved in a release, we will have a Release Champion. The Release Champion will be responsible for a checklist of items for their release. The checklist is an issue template in the Hanzo CD repository.
The Release Champion can be anyone in the Hanzo CD community. Some tasks (like cherry-picking bug fixes and cutting releases) require Approver membership. The Release Champion can delegate tasks when necessary and will be responsible for coordinating with the Approver.
Feature Acceptance Criteria
To be eligible for inclusion in a minor release, a new feature must meet the following criteria before the release’s RC date.
If it is a large feature that involves significant design decisions, that feature must be described in a Proposal, and that Proposal must be reviewed and merged.
The feature PR must include:
- Tests (passing)
- Documentation
- If necessary, a note in the Upgrading docs for the planned minor release
- The PR must be reviewed, approved, and merged by an Approver.
If these criteria are not met by the RC date, the feature will be ineligible for inclusion in the RC series or GA for that minor release. It will have to wait for the next minor release.
Security Patch Policy
CVEs in Hanzo CD code will be patched for all supported versions. Read more about supported versions in the security policy for Hanzo CD.
Dependencies Lifecycle Policy
Dependencies are evaluated before being introduced to ensure they:
-
are actively maintained
-
are maintained by trustworthy maintainers
These evaluations vary from dependency to dependencies.
Dependencies are also scheduled for removal if the project has been deprecated or if the project is no longer maintained.
CVEs in dependencies will be patched for all supported versions if the CVE is applicable and is assessed to be of high or critical severity.
Upgrading Helm, Kustomize, git-lfs, and git
Production runtime binaries (Helm, Kustomize, git-lfs) are pinned in hack/tool-versions.sh. The git package is pinned in Dockerfiles via apt. Renovate opens PRs labeled production-binary when newer versions are available; checksum files for downloaded binaries are refreshed automatically in those PRs.
Before each minor release, review and merge any open Renovate PRs for these dependencies. Please note that sometimes an upgrade results in breaking changes that need to be addressed on the Hanzo CD side and documented in the Hanzo CD version upgrade instructions.
Upgrading Go version that Hanzo CD uses
When starting to work on a new Hanzo CD minor release, the Go version needs to be upgraded to the latest available version, in the following places:
- Dockerfile
- test/remote/Dockerfile
- test/container/Dockerfile
- Dockerfile.tilt
- CI - all GitHub workflows that have
GOLANG_VERSIONorgo-versionset
All the above affect the Go version that Hanzo CD is built with and that is shipped in the Hanzo CD image. Also, those are the relevant places to change when we need to cherry-pick bumps of Go version to the previous Hanzo CD releases, for security reasons.
Please note that Go version in go.mod files should only be bumped if we want to use new language features in this Go version. If using the new language features is not required at this point in time, we should leave the go.mod version as is, even after bumping it in CI and in the Dockerfiles, in order to not force Hanzo CD library users to upgrade their Go versions upon upgrading Hanzo CD.