RELEASE-PROCEDURE: update to new schedule

docs/EARLY-RELEASE.md

@@ -8,10 +8,11 @@ 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
+co called "cool down" period), 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.
 
 The question can only be properly asked once a fix has been created and landed
 in the git master branch.
@@ -28,9 +29,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 an non-insignificant 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'.

docs/RELEASE-PROCEDURE.md

@@ -66,23 +66,23 @@ 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 critical problems
+arise, we can insert releases outside of 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 critical 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, we then only focus on fixing bugs and polishing things
+  to make a solid coming release.
 
 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,