Apply suggestions from code review

Co-authored-by: Aurel Canciu <aurelcanciu@gmail.com>
Co-authored-by: Hidde Beydals <hiddeco@users.noreply.github.com>
Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>

docs/release/controllers.md

@@ -37,7 +37,7 @@ which is extremely valuable during early stages of development.
 
 ### Beta version
 
-A beta version API e.g. `v2beta1` is considered well tested and safe to be used.
+A beta version API e.g. `v2beta1` is considered well-tested and safe to use in production.
 
 The schema of objects may change in incompatible ways in a subsequent beta or stable API version.
 The Custom Resources may require editing after a CRD update for which migration instructions will be
@@ -96,11 +96,11 @@ controller release is included in a Flux patch release.
 Minor releases are intended for backwards compatible feature additions and improvements.
 Note that breaking changes may occur if required by a security vulnerability fix.
 
-Minor releases are used when updating Kubernetes dependencies such as `k8s.io/api` from one minor version to another.
+In addition, minor releases are used when updating Kubernetes dependencies such as `k8s.io/api` from one minor version to another.
 
-In effect, this means a minor version will be released for all Flux controllers approximately every four months
+In effect, this means a new minor version will at least be released for all Flux controllers approximately every four months, following each Kubernetes minor version release. To properly validate the controllers against the latest Kubernetes version, we typically allocate a time window of at least two weeks for end-to-end testing of Flux controllers.
-after each Kubernetes minor version release. To properly validate the controllers against the latest Kubernetes version,
+
-we reserve a time window of at least two weeks for Flux controllers end-to-end testing. 
+It is worth noting that in certain scenarios where project dependencies are not in sync with the Kubernetes version or conflicts arise, this two-week timeframe may prove insufficient, requiring additional time to address the issues appropriately.
 
 ### Major releases
 
@@ -123,7 +123,7 @@ new feature or optimisation ahead of schedule.
 
 For Flux controllers we support the last three minor releases.
 
-Security fixes, may be back-ported to those three minor versions as patch releases,
+Security fixes may be back-ported to those three minor versions as patch releases,
 depending on severity and feasibility.
 
 Note that back-porting is provided by the community on a best-effort basis.

docs/release/flux.md

@@ -8,21 +8,21 @@ bundling the [Flux controllers](controllers.md) into a distributable package.
 
 Flux is released by following the [semver](https://semver.org/) conventions:
 
-- `vX.Y.Z-RC.W` release candidates e.g. `v2.0.0-RC.1`
+- `vX.Y.Z-RC.W` release candidates e.g. `v2.0.0-rc.1`
 - `vX.Y.Z` stable releases e.g. `v2.0.0`
 
 The Flux project maintains release branches for the most recent three minor releases
-e.g. `release-2.0`, `release-2.1` and `release-2.2`.
+e.g. `release/2.0.x`, `release/2.1.x` and `release/2.2.x`.
 
 ### Release candidates
 
 Release candidates are intended for testing new features or improvements before a final release.
 
-In most cases, a maintainer will publish a release candidate for Flux users to tests it on their
+In most cases, a maintainer will publish a release candidate for Flux users to test on their
 staging clusters. Release candidates are not meant to be deployed in production unless advised
 to do so by a maintainer.
 
-Release candidates can be unstable and they are deprecated by subsequent RC or stable version.
+Release candidates can be unstable and they are deprecated by subsequent RC or stable versions.
 
 ### Patch releases