docs: Update the release procedure to include release candidates [skip ci]

Fixes #6456

docs/markdown/Release-procedure.md

@@ -4,23 +4,42 @@
 
 # Trunk
 
-Meson operates under the principle that trunk should (in theory) be always good enough for release. That is, all code merged in trunk must pass all unit tests. Any broken code should either be fixed or reverted immediately.
+Meson operates under the principle that trunk should (in theory) be always
+good enough for release. That is, all code merged in trunk must pass all unit
+tests. Any broken code should either be fixed or reverted immediately.
 
-People who are willing to tolerate the occasional glitch should be able to use Meson trunk for their day to day development if they so choose.
+People who are willing to tolerate the occasional glitch should be able to
+use Meson trunk for their day to day development if they so choose.
 
 # Major releases
 
-Major releases are currently in the form 0.X.0, where X is an increasing number. We aim to do a major release roughly once a month, though the schedule is not set in stone. Prior to the release there is a stabilisation period of roughly a week. Major changes should not be committed during this time, but instead only small scale fixes.
+Major releases are currently in the form 0.X.0, where X is an increasing
+number. We aim to do a major release roughly once a month, though the
+schedule is not set in stone.
+
+Before a major release is made a stable branch will be made, and 0.X.0-rc1
+release candidate will be made. A new milestone for 0.X.0 will be made, and
+all bugs effecting the RC will be assigned to this milestone. Patches fixing
+bugs in the milestone will be picked to the stable branch, and normal
+development will continue on the master branch. Every week after after this a
+new release candidate will be made until all bugs are resolved in that
+milestone. When all of the bugs are fixed the 0.X.0 release will be made.
 
 # Bugfix releases
 
-Bugfix releases contain only minor fixes to major releases and are designated by incrementing the last digit of the version number. The criteria for a bug fix release is one of the following:
+Bugfix releases contain only minor fixes to major releases and are designated
+by incrementing the last digit of the version number. The criteria for a bug
+fix release is one of the following:
 
- - release has a major regression compared to the previous release (making existing projects unbuildable)
+ - release has a major regression compared to the previous release (making
+   existing projects unbuildable)
  - the release has a serious bug causing data loss or equivalent
  - other unforeseen major issue
 
-In these cases a bug fix release can be made. It shall contain _only_ the fix for the issue (or issues) in question and other minor bug fixes. Only changes that have already landed in trunk will be considered for inclusion. No new functionality shall be added.
+In these cases a bug fix release can be made. It shall contain _only_ the fix
+for the issue (or issues) in question and other minor bug fixes. Only changes
+that have already landed in trunk will be considered for inclusion. No new
+functionality shall be added.
 
 # Requesting a bug fix release
 
@@ -28,7 +47,8 @@ The process for requesting that a bug fix release be made goes roughly as follow
 
  - file a bug about the core issue
  - file a patch fixing it if possible
- - contact the development team and request a bug fix release (IRC is the preferred contact medium)
+ - contact the development team and request a bug fix release (IRC is the
+   preferred contact medium)
 
 The request should contain the following information:
 
@@ -38,4 +58,7 @@ The request should contain the following information:
 
 There is no need to write a long and complicated request report. Something like the following is sufficient:
 
-> The latest release has a regression where trying to do Foo using Bar breaks. This breaks all projects that use both, which includes at least [list of affected projects]. This causes problems for X amount of people and because of this we should do a bugfix release.
+> The latest release has a regression where trying to do Foo using Bar
+breaks. This breaks all projects that use both, which includes at least [list
+of affected projects]. This causes problems for X amount of people and
+because of this we should do a bugfix release.