RELEASE-PROCEDURE: update to new schedule

Ref: https://curl.se/mail/lib-2023-03/0062.html

Assisted-by: Andy Alt
Assisted-by: Dan Frandrich

Closes #10827

docs/EARLY-RELEASE.md

@@ -8,12 +8,12 @@ away".
 
 ## Bugfix
 
-During the release cycle, and especially in the beginning of a new cycle,
-there are times when a bug is reported and after it has been subsequently
-fixed correctly, the discussion might be brought up: is this bug and
-associated fix important enough for an early patch release.
+During the release cycle, and especially in the beginning of a new cycle (the
+so-called "cool down" period), there are times when a bug is reported and
+after it has been subsequently fixed correctly, the question might be asked:
+is this bug and associated fix important enough for an early patch release?
 
-The question can only be properly asked once a fix has been created and landed
+The question can only be properly asked when a fix has been created and landed
 in the git master branch.
 
 ## Early release
@@ -28,9 +28,10 @@ big and we never release just a patch. There is only "release".
  - Is there a security advisory rated high or critical?
  - Is there a data corruption bug?
  - Did the bug cause an API/ABI breakage?
+ - Will the problem annoy a significant share of the user population?
 
-If the answer is yes to one or more of the above, an early release might
-indeed be warranted.
+If the answer is yes to one or more of the above, an early release might be
+warranted.
 
 More questions to ask ourselves when doing the assessment if the answers to
 the three ones above are all 'no'.
@@ -49,7 +50,7 @@ the three ones above are all 'no'.
  - Is it a regression? Is the bug introduced in this release?
  - Can the bug be fixed "easily" by applying a patch?
  - Does the bug break the build? Most users don't build curl themselves.
- - How long is it left until the already scheduled next release?
+ - How long is it until the already scheduled next release?
  - Can affected users safely rather revert to a former release until the next
    scheduled release?
  - Is it a performance regression with no functionality side-effects? If so it
@@ -58,7 +59,7 @@ the three ones above are all 'no'.
 ## If an early release is deemed necessary
 
 Unless done for security or similarly important reasons, an early release
-should never be done within two weeks of the release of the previous version.
+should not be done within a week of the previous release.
 
 This, to enable us to collect and bundle more fixes into the same release to
 make the release more worthwhile for everyone and to allow more time for fixes

docs/RELEASE-PROCEDURE.md

@@ -66,27 +66,27 @@ curl release scheduling
 Release Cycle
 -------------
 
-We do releases every 8 weeks on Wednesdays. If critical problems arise, we can
-insert releases outside of the schedule or we can move the release date - but
-this is rare.
+We normally do releases every 8 weeks on Wednesdays. If important problems
+arise, we can insert releases outside the schedule or we can move the release
+date.
 
-Each 8 week release cycle is split in two 4-week periods.
+Each 8 week (56 days) release cycle is divided into three distinct periods:
 
-- During the first 4 weeks after a release, we allow new features and changes
-  to curl and libcurl. If we accept any such changes, we bump the minor number
-  used for the next release.
+- During the first 10 calendar days after a release, we are in "cool down". We
+  do not merge features but only bug-fixes. If a regression is reported, we
+  might do a follow-up patch release.
 
-- During the second 4-week period we do not merge any features or changes, we
-  then only focus on fixing bugs and polishing things to make a solid coming
-  release.
+- During the following 3 weeks (21 days) there is a feature window: we allow
+  new features and changes to curl and libcurl. If we accept any such changes,
+  we bump the minor number used for the next release.
 
-- After a regular procedure-following release (made on Wednesdays), the
-  feature window remains closed until the following Monday in case of special
-  actions or patch releases etc.
+- During the next 25 days we are in feature freeze. We do not merge any
+  features or changes, and we only focus on fixing bugs and polishing things
+  to make the pending release a solid one.
 
 If a future release date happens to end up on a "bad date", like in the middle
-of common public holidays or when the lead release manager is away traveling,
-the release date can be moved forwards or backwards a full week. This is then
+of common public holidays or when the lead release manager is unavailable, the
+release date can be moved forwards or backwards a full week. This is then
 advertised well in advance.
 
 Critical problems
@@ -107,7 +107,6 @@ Coming dates
 Based on the description above, here are some planned release dates (at the
 time of this writing):
 
-- March 20, 2023 (8.0.0 - curl 25 years)
 - May 17, 2023
 - July 19, 2023
 - September 6, 2023
@@ -115,3 +114,4 @@ time of this writing):
 - December 27, 2023
 - February 21, 2024
 - April 17, 2024
+- June 12, 2024