Merge pull request #177 from graphql-java/updated-release-policy

Update release policy

Author: dondonz

blog/2023-03-21-release-policy.md

@@ -7,18 +7,21 @@ slug: release-policy
 We’re formalising our release schedule to give the community a better idea of when to expect releases, what will be contained within them, and when important fixes will be backported.
 
 ## General release schedule
-Going forward, we plan to have 4 releases every year, approximately one per quarter. We will alternate between releases containing breaking changes, and releases containing features and bugfixes (without breaking changes).
+:::caution
+Since this blog post was published, we changed our release schedule from 4 times to 3 times per year.
+:::
+Going forward, we plan to have 3 releases every year. We will alternate between releases containing breaking changes, and releases containing features and bugfixes (without breaking changes).
 
-For example: our next release 20.1 will be in late March 2023, and this will be a feature and bugfix release without breaking changes. Therefore, we’re going to retain Java 8 in the 20.1 release. Our subsequent quarterly release will be around early July 2023 and will contain breaking changes, including upgrading to Java 11.
+For example: our next release 20.1 will be in late March 2023, and this will be a feature and bugfix release without breaking changes. Therefore, we’re going to retain Java 8 in the 20.1 release. Our subsequent release will be around early July 2023 and will contain breaking changes, including upgrading to Java 11.
 
 ## Security backports
-We will backport critical bugfixes and security fixes for versions dating back 18 months (or roughly 6 versions). These fixes will be backported depending on severity and demand. As security fixes are time sensitive, we will release them on demand instead of waiting for the next quarterly release date.
+We will backport critical bugfixes and security fixes for versions dating back 18 months. These fixes will be backported depending on severity and demand. As security fixes are time sensitive, we will release them on demand instead of waiting for the next release date.
 
 ## Bugfix backports
-We will backport important bug fixes at most 12 months (or roughly 4 versions). These fixes will be backported depending on the severity of the bug and demand.
+We will backport important bug fixes at most 12 months. These fixes will be backported depending on the severity of the bug and demand.
 
 ## Deprecations
-When code is deprecated, we will wait at least 12 months before removing it (or roughly 4 versions).
+When code is deprecated, we will wait at least 12 months before removing it.
 
 ## Version numbering
 We will continue to use `major.minor` version numbering.

documentation/sdl-directives.md

@@ -30,7 +30,7 @@ type Employee
 }
 ```
 
-Publishing ``salary`` information to every one who can see this employee's ``name`` might not be want you want.  Rather you want some sort of access control
+Publishing ``salary`` information to every one who can see this employee's ``name`` might not be what you want.  Rather you want some sort of access control
 to be in place such that if your role is that of a manager, you can see salaries, otherwise you get no data back.
 
 Directives can help you declare this more easily.  Our declaration above would become something like the following: