From 4315d7d5cc0ef91acea7c23b13f4e6638aa91950 Mon Sep 17 00:00:00 2001 From: Anton Gilgur Date: Sat, 1 Jun 2024 23:41:45 -0400 Subject: [PATCH] docs: minor copy-edits to releases page - did a full style guide audit of this page too, similar to my previous PRs, but there wasn't _too_ much to change here - put italics around the fact that Argo doesn't use SemVer -- just to be _more_ explicit - remove duplicated note about breaking changes being listed in the upgrading guide - the next section says the same thing - simplify release cycle section, per [k8s style guide](https://kubernetes.io/docs/contribute/style/style-guide/#use-simple-and-direct-language) - replace use of jargon such as "shipped", per [k8s style guide](https://kubernetes.io/docs/contribute/style/style-guide/#avoid-jargon-and-idioms) - use more consistent language as well - introduce RCs and capitalize the terms, then use the term RC - use "version" and "release" consistently - prefer 1 sentence per line of markdown, per [style guide](https://argo-workflows.readthedocs.io/en/release-3.5/doc-changes/) - fix some minor grammar issues (missing articles, extra comma, etc) Signed-off-by: Anton Gilgur --- docs/releases.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/docs/releases.md b/docs/releases.md index a84cee499d4f..9fa01789c146 100644 --- a/docs/releases.md +++ b/docs/releases.md @@ -1,26 +1,24 @@ # Releases -You can find the most recent version under [Github release](https://github.com/argoproj/argo-workflows/releases). +You can find the most recent version in the [GitHub Releases](https://github.com/argoproj/argo-workflows/releases). ## Versioning -Versions are expressed as `x.y.z`, where `x` is the major version, `y` is the minor version, and `z` is the patch version, -following Semantic Versioning terminology. +Versions are expressed as `x.y.z`, where `x` is the major version, `y` is the minor version, and `z` is the patch version, following Semantic Versioning terminology. -Argo Workflows does not use Semantic Versioning. Minor versions may contain breaking changes. Patch versions only -contain bug fixes and minor features. +Argo Workflows does _not_ use Semantic Versioning. +Minor versions may contain breaking changes. +Patch versions only contain bug fixes and minor features. For **stable**, use the latest patch version. -⚠️ Read the [upgrading guide](upgrading.md) to find out about breaking changes before any upgrade. - ## Supported Versions We maintain release branches for the most recent two minor releases. -Fixes may be back-ported to release branches, depending on severity, risk, and, feasibility. +Fixes may be backported to release branches, depending on severity, risk, and feasibility. -Breaking changes will be documented in [upgrading guide](upgrading.md). +Breaking changes will be documented in the [upgrading guide](upgrading.md). ## Supported Version Skew @@ -29,15 +27,16 @@ Both the `argo-server` and `argocli` should be the same version as the controlle ## Release Cycle New minor versions are released roughly every 6 months. +Release Candidates (RCs) for major and minor versions are available roughly 4-6 weeks before General Availability (GA). -Release candidates (RCs) for major and minor releases are typically available for 4-6 weeks before the release becomes generally available (GA). Features may be shipped in subsequent release candidates. - -When features are shipped in a new release candidate, the most recent release candidate will be available for at least 2 weeks to ensure it is tested sufficiently before it is pushed to GA. If bugs are found with a feature and are not resolved within the 2 week period, the features will be rolled back so as to be saved for the next major/minor release timeline, and a new release candidate will be cut for testing before pushing to GA. +Features may be added in subsequent RCs. +If they are, the RC will be available for at least 2 weeks to ensure sufficient testing before GA. +If bugs are found with a feature and not resolved within the 2 week period, it will be rolled back and a new RC will be released before GA. Otherwise, we typically release every two weeks: * Patch fixes for the current stable version. -* The next release candidate, if we are currently in a release-cycle. +* The next RC, if we are currently in a release cycle. ## Kubernetes Compatibility Matrix