keep releases.md in sync with containerd/containerd

Signed-off-by: Samuel Karp <samuelkarp+automated@google.com>

content/releases.md

@@ -3,7 +3,7 @@ title: Versioning and release
 ---
 
 This document details the versioning and release plan for containerd. Stability
-is a top goal for this project and we hope that this document and the processes
+is a top goal for this project, and we hope that this document and the processes
 it entails will help to achieve that. It covers the release process, versioning
 numbering, backporting, API stability and support horizons.
 
@@ -76,7 +76,7 @@ to create the milestone or add an issue or PR to an existing milestone.
 ### Support Horizon
 
 Support horizons will be defined corresponding to a release branch, identified
-by `<major>.<minor>`. Releases branches will be in one of several states:
+by `<major>.<minor>`. Release branches will be in one of several states:
 
 - __*Next*__: The next planned release branch.
 - __*Active*__: The release is a stable branch which is currently supported and accepting patches.
@@ -98,7 +98,7 @@ backports until the end of life date. They may also accept a wider range of
 patches than non-_LTS_ releases to support the longer term maintainability of the
 branch, including library dependency, toolchain (including Go) and other version updates
 which are needed to ensure each release is built with fully supported dependencies and
-remains usable by containerd clients. There should be at least a 6 month overlap between
+remains usable by containerd clients. There should be at least a 6-month overlap between
 the end of life of an _LTS_ release and the initial release of a new _LTS_ release.
 Up to 6 months before the announced end of life of an _LTS_ branch, the branch may
 convert to a regular _Active_ release with stricter backport criteria.
@@ -159,7 +159,7 @@ Deprecated containerd and kubernetes versions
 Backports in containerd are community driven. As maintainers, we'll try to
 ensure that sensible bugfixes make it into _active_ release, but our main focus
 will be features for the next _minor_ or _major_ release. For the most part,
-this process is straightforward and we are here to help make it as smooth as
+this process is straightforward, and we are here to help make it as smooth as
 possible.
 
 If there are important fixes that need to be backported, please let us know in
@@ -180,7 +180,7 @@ fairly straightforward. The steps differ depending on whether you are pulling
 a fix from main or need to draft a new commit specific to a particular
 branch.
 
-To cherry pick a straightforward commit from main, simply use the cherry pick
+To cherry-pick a straightforward commit from main, simply use the cherry-pick
 process:
 
 1. Pick the branch to which you want backported, usually in the format
@@ -279,7 +279,7 @@ Plugins implemented in tree are supported by the containerd community unless exp
 Out of tree plugins are not supported by the containerd maintainers.
 
 Currently, the Windows runtime and snapshot plugins are not stable and not supported.
-Please refer to the github milestones for Windows support in a future release.
+Please refer to the GitHub milestones for Windows support in a future release.
 
 #### Error Codes
 
@@ -291,7 +291,7 @@ new version of the service.
 
 If you find that an error code that is required by your application is not
 well-documented in the protobuf service description or tested explicitly,
-please file and issue and we will clarify.
+please file an issue and we will clarify.
 
 #### Opaque Fields
 
@@ -319,7 +319,7 @@ be a matter of fixing compilation errors and moving from there.
 
 The CRI (Container Runtime Interface) GRPC API is used by a Kubernetes kubelet
 to communicate with a container runtime. This interface is used to manage
-container lifecycles and container images. Currently this API is under
+container lifecycles and container images. Currently, this API is under
 development and unstable across Kubernetes releases. Each Kubernetes release
 only supports a single version of CRI and the CRI plugin only implements a
 single version of CRI.
@@ -332,7 +332,7 @@ version of Kubernetes which supports that version of CRI.
 
 The `ctr` tool provides the ability to introspect and understand the containerd
 API. It is not considered a primary offering of the project and is unsupported in
-that sense. While we understand it's value as a debug tool, it may be completely
+that sense. While we understand its value as a debug tool, it may be completely
 refactored or have breaking changes in _minor_ releases.
 
 Targeting `ctr` for feature additions reflects a misunderstanding of the containerd