Merge branch 'main' into corymhall/upgrade-jest

packages/@aws-cdk-testing/cli-integ/README.md

@@ -3,13 +3,7 @@
 
 ---
 
-![cdk-constructs: Experimental](https://img.shields.io/badge/cdk--constructs-experimental-important.svg?style=for-the-badge)
-
-> The APIs of higher level constructs in this module are experimental and under active development.
-> They are subject to non-backward compatible changes or removal in any future version. These are
-> not subject to the [Semantic Versioning](https://semver.org/) model and breaking changes will be
-> announced in the release notes. This means that while you may use them, you may need to update
-> your source code when upgrading to a newer version of this package.
+![cdk-constructs: Stable](https://img.shields.io/badge/cdk--constructs-stable-success.svg?style=for-the-badge)
 
 ---
 

packages/@aws-cdk-testing/cli-integ/package.json

@@ -66,8 +66,8 @@
   "engines": {
     "node": ">= 14.15.0"
   },
-  "stability": "experimental",
-  "maturity": "experimental",
+  "stability": "stable",
+  "maturity": "stable",
   "publishConfig": {
     "tag": "latest"
   }

packages/@aws-cdk/aws-batch-alpha/README.md

@@ -316,7 +316,7 @@ For example, a `shareDecay` of 5 minutes in the above example means that at any
 will be scheduled for each `'B'` job, but only for the past 5 minutes. If `'B'` jobs run longer than 5 minutes, then
 the scheduler is allowed to put more than two `'A'` jobs for each `'B'` job, because the usage of those long-running
 `'B'` jobs will no longer be considered after 5 minutes. `shareDecay` linearly decreases the usage of
-long running jobs for calculation purposes. eg if share decay is 60 seconds,
+long running jobs for calculation purposes. For example if share decay is 60 seconds,
 then jobs that run for 30 seconds have their usage considered to be only 50% of what it actually is,
 but after a whole minute the scheduler pretends they don't exist for fairness calculations.
 
@@ -342,7 +342,7 @@ where `ActiveFairShares` is the number of shares for which there exists
 at least one job in the queue with a unique share identifier.
 
 This is best illustrated with an example.
-Suppose there three shares with share identifiers `A`, `B` and `C` respectively
+Suppose there are three shares with share identifiers `A`, `B` and `C` respectively
 and we specify the `computeReservation` to be 75%. The queue is currently empty,
 and no other shares exist.
 
@@ -365,7 +365,7 @@ so the percentage reserved is still 56.25%
 Now a `C` job enters the queue. The number of active fair shares is now 3,
 so (75/100)^3 = .421875 = 42.1875% of the maximum vCpus are reserved for all shares that do not have the identifier `A`, `B`, or `C`.
 
-If these are no other shares that your jobs can specify, this means that 42.1875% of your capacity will never be used!
+If there are no other shares that your jobs can specify, this means that 42.1875% of your capacity will never be used!
 
 Now, `A`, `B`, and `C` can only consume 100% - 42.1875% = 57.8125% of the maximum vCpus.
 Note that the this percentage is **not** split between `A`, `B`, and `C`.
@@ -440,8 +440,8 @@ they must all match for the action to be taken; the conditions are ANDed togethe
 
 ### Running single-container ECS workflows
 
-Batch can jobs on ECS or EKS. ECS jobs can defined as single container or multinode.
-This examples creates a `JobDefinition` that runs a single container with ECS:
+Batch can run jobs on ECS or EKS. ECS jobs can be defined as single container or multinode.
+This example creates a `JobDefinition` that runs a single container with ECS:
 
 ```ts
 import * as cdk from 'aws-cdk-lib';