From 2c7ecda5559ed19a2d13c76109694a92c5635150 Mon Sep 17 00:00:00 2001 From: Fish-pro Date: Tue, 17 Jan 2023 11:25:34 +0800 Subject: [PATCH] Fix syntax errors in the document Signed-off-by: Fish-pro --- docs/Backwards_Compatibility.md | 2 +- docs/RELEASE.md | 12 ++++++------ docs/Release_Management.md | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/Backwards_Compatibility.md b/docs/Backwards_Compatibility.md index 4f28876bfa7..1056f35634e 100644 --- a/docs/Backwards_Compatibility.md +++ b/docs/Backwards_Compatibility.md @@ -102,7 +102,7 @@ is that unlike enums, which have a bounded set of allowed values, the set of valid enforcement actions is unbounded. This makes it more akin to a [union set](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#unions). -Currently Gatekeeper is deviating slightly from the `enforcementAction` spec by +Current Gatekeeper is deviating slightly from the `enforcementAction` spec by defaulting to rejecting constraints with an unknown enforcement action (this behavior can be disabled via the `--disable-enforcementaction-validation` flag). This should be a non-issue as a missing constraint and an ignored constraint are diff --git a/docs/RELEASE.md b/docs/RELEASE.md index b6ae1c4541e..63ba92fcba0 100644 --- a/docs/RELEASE.md +++ b/docs/RELEASE.md @@ -15,24 +15,24 @@ Building involves obtaining a copy of the repository and triggering a build as p Publishing involves creating a release tag and creating a new *Release* on GitHub. -## Cherry picking +## Cherry-picking -There is an optional script for cherry picking PRs that should make the process easier. +There is an optional script for cherry-picking PRs that should make the process easier. Prerequisites: - `hub` binary is installed. If not, `hub` can be installed by `go get github.com/github/hub`. -- Set GitHub user name with `export GITHUB_USER=` +- Set GitHub username with `export GITHUB_USER=` - Set fork remote with `export FORK_REMOTE=` - Set upstream remote with `export UPSTREAM_REMOTE=` Usage: `./third_party/k8s.io/kubernetes/hack/cherry_pick_pull.sh upstream/release-3.1 123` -For example, this will cherry pick PR #123 into `upstream/release-3.1` branch and will create a PR for you. +For example, this will cherry-pick PR #123 into `upstream/release-3.1` branch and will create a PR for you. You can also combine multiple PRs by separating them with spaces (`./third_party/k8s.io/kubernetes/hack/cherry_pick_pull.sh upstream/release-3.1 123 456`) If you want to run the script with dry run mode, set `DRY_RUN` to `true`. -Cherry pick script is copied over from https://github.com/kubernetes/kubernetes/blob/master/hack/cherry_pick_pull.sh. For more information, see https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md +Cherry-pick script is copied over from https://github.com/kubernetes/kubernetes/blob/master/hack/cherry_pick_pull.sh. For more information, see https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md ## Release Cadence @@ -48,7 +48,7 @@ Once we are ready to release the new minor version, we will create a release bra Once we are confident in our latest release candidate, we will tag the release branch with a stable release (`vX.Y+1.0`), and the development cycle will start all over again. We recommend using stable releases of Gatekeeper in a production environment. We also encourage users to upgrade to the latest stable patch releases (`vX.Y+1.Z`) for bug fixes, security fixes, and performance improvements. -For patch releases (e.g. `vX.Y.1`), refer to the [cherry picking](#cherry-picking) section on how to cherry-pick merged pull requests to an existing release branch. +For patch releases (e.g. `vX.Y.1`), refer to the [cherry-picking](#cherry-picking) section on how to cherry-pick merged pull requests to an existing release branch. ## Release Pull Requests diff --git a/docs/Release_Management.md b/docs/Release_Management.md index 4063defbde2..e5f35fd8b3e 100644 --- a/docs/Release_Management.md +++ b/docs/Release_Management.md @@ -7,8 +7,8 @@ This document describes Gatekeeper project release management, which includes re ## Legend - **X.Y.Z** refers to the version (git tag) of Gatekeeper that is released. This is the version of the Gatekeeper image and the Chart version. -- **Breaking changes** refer to schema changes, flag changes, and behavior changes of Gatekeeper that may require a clean install during upgrade and it may introduce changes that could break backward compatibility. -- **Milestone** should be designed to include feature sets to accommodate 2 months release cycles including test gates. GitHub milestones are used by maintainers to manage each release. PRs and Issues for each release should be created as part of a corresponding milestone. +- **Breaking changes** refer to schema changes, flag changes, and behavior changes of Gatekeeper that may require a clean installation during upgrade, and it may introduce changes that could break backward compatibility. +- **Milestone** should be designed to include feature sets to accommodate 2 months release cycles including test gates. GitHub's milestones are used by maintainers to manage each release. PRs and Issues for each release should be created as part of a corresponding milestone. - **Patch releases** refer to applicable fixes, including security fixes, may be backported to support releases, depending on severity and feasibility. - **Test gates** should include soak tests and upgrade tests from the last minor version. @@ -52,7 +52,7 @@ Applicable fixes, including security fixes, may be cherry-picked into the releas We expect users to stay reasonably up-to-date with the versions of Gatekeeper they use in production, but understand that it may take time to upgrade. We expect users to be running approximately the latest patch release of a given minor release and encourage users to upgrade as soon as possible. -We expect to "support" n (current) and n-1 major.minor releases. "Support" means we expect users to be running that version in production. For example, when v3.3.0 comes out, v3.1.x will no longer be supported for patches and we encourage users to upgrade to a supported version as soon as possible. +We expect to "support" n (current) and n-1 major.minor releases. "Support" means we expect users to be running that version in production. For example, when v3.3.0 comes out, v3.1.x will no longer be supported for patches, and we encourage users to upgrade to a supported version as soon as possible. ## Supported Kubernetes Versions