[ci skip] Update release process docs to Markdown

- Markdown
- CS syncs
- Some partial readability fixes
- The protocol hasn't been changed

1 files changed, 316 insertions, 277 deletions

diff --git a/docs/release-process.md b/docs/release-process.md
index fdc2440748..97fe16649c 100644
--- a/docs/release-process.md
+++ b/docs/release-process.md
@@ -1,398 +1,437 @@
-=======================
-  PHP Release Process
-=======================
+# PHP release process
 
-General notes and tips
-----------------------
+## General notes and tips
 
-1. Do not release on Fridays, Saturdays or Sundays
-because the sysadmins can not upgrade stuff then.
+ 1. Do not release on Fridays, Saturdays or Sundays because the sysadmins cannot
+    upgrade stuff then.
 
-2. Package two days before a release. So if the release is to be on Thursday,
-package on Tuesday. Think about timezones as well.
+ 2. Package two days before a release. So if the release is to be on Thursday,
+    package on Tuesday. Think about timezones as well.
 
-3. Ensure that the tests on Travis CI are green.
-See: https://travis-ci.org/php/php-src/builds
-It is recommended to do so a couple of days before the packaging day, to
-have enough time to investigate failures, communicate with the authors and
-commit the fixes.
-The RM for the branch is also responsible for keeping the CI green on
-ongoing basis between the releases. Check the CI status for your branch
-periodically and resolve the failures ASAP. See more in:
-https://wiki.php.net/rfc/travis_ci
+ 3. Ensure that the tests on Travis CI are green.
 
-4. Ensure that Windows builds will work before packaging
+    See: https://travis-ci.org/php/php-src/builds
 
-5. Follow all steps to the letter. When unclear ask previous RM's (David/Julien/
-Johannes/Stas/Derick/Ilia) before proceeding. Ideally make sure that for the
-first releases one of the previous RM's is around to answer questions. For the
-steps related to the php/QA/bug websites try to have someone from the webmaster
-team (Bjori) on hand.
+    It is recommended to do so a couple of days before the packaging day, to
+    have enough time to investigate failures, communicate with the authors and
+    commit the fixes.
 
-6. Verify the tags to be extra sure everything was tagged properly.
+    The RM for the branch is also responsible for keeping the CI green on
+    ongoing basis between the releases. Check the CI status for your branch
+    periodically and resolve the failures ASAP. See more in
+    https://wiki.php.net/rfc/travis_ci.
 
-7. Moving extensions from/to PECL requires write access to the destination.
-Most developers should have this.
+ 4. Ensure that Windows builds will work before packaging.
 
-Moving extensions from php-src to PECL
-- Checkout the pecl directory, most likely you want a sparse-root checkout
-  svn co --depth=empty https://svn.php.net/repository/pecl
-- Create a directory for the extension incl. branch and tag structure,
-  no trunk at this point and commit this to svn
-  cd pecl; mkdir foo foo/tags foo/branches; svn add foo; svn commit
-- Move the extension from php-src to the new location
-  svn mv https://svn.php.net/repository/php/php-src/trunk/ext/foo \
-         https://svn.php.net/repository/pecl/foo/trunk
+ 5. Follow all steps to the letter. When unclear ask previous RM's (David,
+    Julien, Johannes, Stas, Derick, Ilia, Sara, Remi, or Christoph) before
+    proceeding. Ideally make sure that for the first releases one of the
+    previous RM's is around to answer questions. For the steps related to the
+    php/QA/bug websites try to have someone from the webmaster team (Bjori) on
+    hand.
 
-If the extension is still usable or not dead, in cooperation with the extension
-maintainers if any:
-- create the pecl.php.net/foo package and its content, license, maintainer
-- create the package.xml, commit
-- release the package
+ 6. Verify the tags to be extra sure everything was tagged properly.
 
-For Moving extensions from PECL to php-src the svn mv has to be done the other
-way round.
+ 7. Moving extensions from/to PECL requires write access to the destination.
+    Most developers should have this.
 
-Rolling a non stable release (alpha/beta/RC)
---------------------------------------------
+    Moving extensions from php-src to PECL:
 
-1. Check windows snapshot builder logs (http://windows.php.net/downloads/snaps/ the last revision)
+    * Checkout the pecl directory, most likely you want a sparse-root checkout
 
-2. Check the tests at https://travis-ci.org/php/php-src/builds
+        ```
+        svn co --depth=empty https://svn.php.net/repository/pecl
+        ```
 
-3. run the "scripts/dev/credits" script in php-src and commit the changes in the
-credits files in ext/standard.
+    * Create a directory for the extension including branch and tag structure,
+      no trunk at this point and commit this to svn
 
-4. Checkout the release branch for this release (e.g., PHP-5.4.2) from the main branch.
+      ```
+      cd pecl; mkdir foo foo/tags foo/branches; svn add foo; svn commit
+      ```
 
-5. Bump the version numbers in ``main/php_version.h``, ``Zend/zend.h``, ``configure.ac`` and possibly ``NEWS``.
-Do not use abbreviations for alpha and beta. Do not use dashes, you should
-``#define PHP_VERSION "5.4.22RC1"`` and not ``#define PHP_VERSION "5.4.22-RC1"``
+    * Move the extension from php-src to the new location
 
-6. Compile and make test, with and without ZTS, using the right Bison version
-(for example, for 5.5, Bison 2.4.1 is used)
+      ```
+      svn mv https://svn.php.net/repository/php/php-src/trunk/ext/foo \
+      https://svn.php.net/repository/pecl/foo/trunk
+      ```
 
-7. Check ./sapi/cli/php -v output for version matching.
+    If the extension is still usable or not dead, in cooperation with the
+    extension maintainers if any:
+    * Create the pecl.php.net/foo package and its content, license, maintainer
+    * Create the package.xml, commit
+    * Release the package
 
-8. If all is right, commit the changes to the release branch with ``git commit -a``.
+    For moving extensions from PECL to php-src the svn mv has to be done the
+    other way round.
 
-9. Tag the repository release branch with the version, e.g.:
-``git tag -u YOURKEYID php-5.4.2RC2``
+## Rolling a non stable release (alpha/beta/RC)
 
-10. Bump the version numbers in ``main/php_version.h``, ``Zend/zend.h``, ``configure.ac`` and ``NEWS``
-in the *main* branch (PHP-5.4 for example) to prepare for the **next** version.
-F.e. if the RC is "5.4.1RC1" then the new one should be "5.4.2-dev" - regardless if we get
-a new RC or not. This is to make sure ``version_compare()`` can correctly work.
-Commit the changes to the main branch.
+ 1. Check Windows snapshot builder logs https://windows.php.net/downloads/snaps/
+    the last revision.
 
-11. Push the changes to the main repo, the tag, the main branch and the release branch :
-``git push --tags origin HEAD``
-``git push origin {main branch}``
-``git push origin {release branch}``
+ 2. Check the tests at https://travis-ci.org/php/php-src/builds.
 
-12. run: ``PHPROOT=. ./scripts/dev/makedist 5.4.2RC2``, this will export the tree, create configure
-and build three tarballs (gz, bz2 and xz).
+ 3. Run the `scripts/dev/credits` script in php-src and commit the changes in
+    the credits files in ext/standard.
 
-13. run ``scripts/dev/gen_verify_stub <version> [identity]``, this will sign the tarballs
-and output verification information to be included in announcement email
+ 4. Checkout the release branch for this release (e.g., PHP-5.4.2) from the main
+    branch.
 
-14. Copy those tarballs (scp, rsync) to downloads.php.net, in your homedir there should be a
-directory "public_html/". Copy them into there. If you do not have this directory, create it.
+ 5. Bump the version numbers in `main/php_version.h`, `Zend/zend.h`,
+    `configure.ac` and possibly `NEWS`. Do not use abbreviations for alpha and
+    beta. Do not use dashes, you should `#define PHP_VERSION "5.4.22RC1"` and
+    not `#define PHP_VERSION "5.4.22-RC1"`
 
-15. Now the RC can be found on http://downloads.php.net/~yourname,
-f.e. http://downloads.php.net/~derick/
+ 6. Compile and run `make test`, with and without ZTS, using the right Bison
+    version (for example, for PHP 7.4, minimum Bison 3.0.0 is used).
 
-16. Once the release has been tagged, contact the release-managers@ distribution list
-so that Windows binaries can be created.  Once those are made, they can be found at
-http://windows.php.net/download
+ 7. Check `./sapi/cli/php -v` output for version matching.
 
-Getting the non stable release (alpha/beta/RC) announced
---------------------------------------------------------
+ 8. If all is right, commit the changes to the release branch:
 
-1. Update ``qa.git/include/release-qa.php`` with the appropriate information.
-   See the documentation within release-qa.php for more information, but all releases
-   and RCs are configured here. Only $QA_RELEASES needs to be edited.
+    ```
+    git commit -a
+    ```
 
-   Example: When rolling an RC, set the 'rc' with appropriate information for the
-   given version.
+ 9. Tag the repository release branch with the version, e.g.:
 
-   Note: Remember to update the sha256 checksum information.
+    ```
+    git tag -u YOURKEYID php-5.4.2RC2
+    ```
 
-2. Update ``web/php.git/include/version.inc`` (X_Y=major_minor version number)
+10. Bump the version numbers in `main/php_version.h`, `Zend/zend.h`,
+    `configure.ac` and `NEWS` in the *main* branch (PHP-5.4 for example) to
+    prepare for the **next** version. F.e. if the RC is "5.4.1RC1" then the new
+    one should be `5.4.2-dev` - regardless if we get a new RC or not. This is to
+    make sure `version_compare()` can correctly work. Commit the changes to the
+    main branch.
 
- a. ``$PHP_X_Y_RC`` = "5.4.0RC1"  (should be set to "false" before)
+11. Push the changes to the main repo, the tag, the main branch and the release
+    branch:
 
- b. ``$PHP_X_Y_RC_DATE`` = "06 September 2007"
+    ```
+    git push --tags origin HEAD
+    git push origin {main branch}
+    git push origin {release branch}
+    ```
 
-3. Skip this step for non stable releases after GA of minor or major versions
-   (e.g. announce 7.3.0RC1, but not 7.3.1RC1):
+12. Run: `PHPROOT=. ./scripts/dev/makedist 5.4.2RC2`, this will export the tree,
+    create `configure` and build three tarballs (gz, bz2 and xz).
 
-   Add a short notice to phpweb stating that there is a new release, and
-   highlight the major important things (security fixes) and when it is
-   important to upgrade.
+13. Run `scripts/dev/gen_verify_stub <version> [identity]`, this will sign the
+    tarballs and output verification information to be included in announcement
+    email.
 
- a. Call php bin/createNewsEntry in your local phpweb checkout
-    Use category "frontpage" *and* "releases" for all stable releases.
-    Use category "frontpage" for X.Y.0 non-stable releases only (news only).
+14. Copy those tarballs (scp, rsync) to downloads.php.net, in your homedir there
+    should be a directory `public_html/`. Copy them into there. If you do not
+    have this directory, create it.
 
- b. Add the content for the news entry. Be sure to include the text:
-    "THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION!"
+15. Now the RC can be found on https://downloads.php.net/~yourname,
+    f.e. https://downloads.php.net/~derick/.
 
-4. Commit and push changes to qa and web
+16. Once the release has been tagged, contact the release-managers@ distribution
+    list so that Windows binaries can be created. Once those are made, they can
+    be found at https://windows.php.net/download.
 
-*Wait for web and qa sites to update with new information before sending announce*
+## Getting the non stable release (alpha/beta/RC) announced
 
-5. Send **separate** emails **To** ``internals@lists.php.net`` and ``php-general@lists.php.net``
-lists pointing out "the location of the release" and "the possible release date of
-either the next RC, or the final release". Include in this information the verification
-information output by ``gen_verify_stub``.
+ 1. Update `qa.git/include/release-qa.php` with the appropriate information. See
+    the documentation within release-qa.php for more information, but all
+    releases and RCs are configured here. Only $QA_RELEASES needs to be edited.
 
-6. Send **separate** emails (see example here http://news.php.net/php.pear.qa/5201) **To**
-``php-qa@lists.php.net`` and ``primary-qa-tester@lists.php.net``.
-These emails are to notify the selected projects about a new release so that they
-can make sure their projects keep working. Make sure that you have been setup
-as a moderator for ``primary-qa-tester@lists.php.net`` by having someone (Hannes, Dan,
-Derick) run the following commands for you:
+    Example: When rolling an RC, set the 'rc' with appropriate information for
+    the given version.
 
-``ssh lists.php.net``
+    Note: Remember to update the sha256 checksum information.
 
-``sudo -u ezmlm ezmlm-sub ~ezmlm/primary-qa-tester/mod moderator-email-address``
+ 2. Update `web/php.git/include/version.inc` (X_Y=major_minor version number)
 
-Rolling a stable release
-------------------------
+    * `$PHP_X_Y_RC = "5.4.0RC1"` (should be set to `false` before)
+    * `$PHP_X_Y_RC_DATE = "06 September 2007"`
 
-1. Checkout your release branch, you should have created when releasing previous RC
-and bump the version numbers in ``main/php_version.h``, ``Zend/zend.h``, ``configure.ac`` and possibly ``NEWS``.
+ 3. Skip this step for non stable releases after GA of minor or major versions
+    (e.g. announce 7.3.0RC1, but not 7.3.1RC1):
 
-2. If a CVE commit needs to be merged to the release, then have it committed to
-the base branches and merged upwards as usual (f.e commit the CVE fix to 5.3,
-merge to 5.4, 5.5 etc...). Then you can cherry-pick it in your release branch.
-Don't forget to update NEWS manually in an extra commit then.
+    Add a short notice to phpweb stating that there is a new release, and
+    highlight the major important things (security fixes) and when it is
+    important to upgrade.
 
-3. Commit those changes. Ensure the tests at https://travis-ci.org/php/php-src/builds are
-still passing.
+    * Call `php bin/createNewsEntry` in your local phpweb checkout. Use category
+      "frontpage" *and* "releases" for all stable releases. Use category
+      "frontpage" for X.Y.0 non-stable releases only (news only).
 
-4. run the "scripts/dev/credits" script in php-src and commit the changes in the
-credits files in ext/standard.
+    * Add the content for the news entry. Be sure to include the text:
 
-5. Compile and make test, with and without ZTS, using the right Bison version
-(for example, for 5.5, Bison 2.4.1 is used)
+      ```
+      "THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION!"
+      ```
 
-6. Check ./sapi/cli/php -v output for version matching.
+ 4. Commit and push changes to qa and web.
 
-7. tag the repository with the version f.e. "``git tag -u YOURKEYID php-5.4.1``"
+    Wait for web and qa sites to update with new information before sending
+    announce.
 
-8. Push the tag f.e. "``git push origin php-5.4.1``"
+ 5. Send **separate** emails **To** `internals@lists.php.net` and
+    `php-general@lists.php.net` lists pointing out "the location of the release"
+    and "the possible release date of either the next RC, or the final release".
+    Include in this information the verification information output by
+    `gen_verify_stub`.
 
-9. run: ``PHPROOT=. ./scripts/dev/makedist 5.4.1``, this will export the tag, create configure
-and build three tarballs (gz, bz2 and xz).
-   Check if the pear files are updated (phar).
-   On some systems the behavior of GNU tar can default to produce POSIX compliant archives
-with PAX headers. As not every application is compatible with that format, creation of
-archives with PAX headers should be avoided. When packaging on such a system, the GNU tar
-can be influenced by defining the environment variable TAR_OPTIONS='--format=gnu'.
+ 6. Send **separate** emails (see example http://news.php.net/php.pear.qa/5201)
+    **To** `php-qa@lists.php.net` and `primary-qa-tester@lists.php.net`. These
+    emails are to notify the selected projects about a new release so that they
+    can make sure their projects keep working. Make sure that you have been
+    setup as a moderator for `primary-qa-tester@lists.php.net` by having someone
+    (Hannes, Dan, Derick) run the following commands for you:
 
-10. run ``scripts/dev/gen_verify_stub <version> [identity]``, this will sign the tarballs
-    and output verification information to be included in announcement email
+    ```
+    ssh lists.php.net
+    sudo -u ezmlm ezmlm-sub ~ezmlm/primary-qa-tester/mod moderator-email-address
+    ```
 
-11. Commit and push all the tarballs and signature files to web/php-distributions.git,
-    then update the git submodule reference in web/php.git:
-    ``git submodule init;
-    git submodule update;
-    cd distributions;
-    git fetch;
-    git pull --rebase origin master;
-    cd ..;
-    git commit distributions;
-    git push;``
-This is to fetch the last commit id from php-distributions.git and commit this
-last commit id to web/php.git, then, mirrors will now sync
+## Rolling a stable release
 
-12. Once the release has been tagged, contact release managers, windows builders, and package maintainers
-so that they can build releases. Do not send this announcement to any public lists.
+ 1. Checkout your release branch, you should have created when releasing
+    previous RC and bump the version numbers in `main/php_version.h`,
+    `Zend/zend.h`, `configure.ac` and possibly `NEWS`.
 
-Getting the stable release announced
-------------------------------------
+ 2. If a CVE commit needs to be merged to the release, then have it committed to
+    the base branches and merged upwards as usual (f.e commit the CVE fix to
+    5.3, merge to 5.4, 5.5 etc...). Then you can cherry-pick it in your release
+    branch. Don't forget to update `NEWS` manually in an extra commit then.
 
-1. Update phpweb/include/releases.inc with the old release info
-  (updates the download archives)
+ 3. Commit those changes. Ensure the tests at
+    https://travis-ci.org/php/php-src/builds are still passing.
 
- a. You can run ``php bin/bumpRelease 7 2`` where the first number is
-    the major version, and the second number is the minor version
-    (7.2 in this example).
+ 4. Run the `scripts/dev/credits` script in php-src and commit the changes in
+    the credits files in ext/standard.
 
- b. If that fails for any non-trivially fixable reason, you can
-    manually copy the old information to include/releases.inc
+ 5. Compile and make test, with and without ZTS, using the right Bison version
+    (for example, for PHP 7.4, minimum Bison 3.0.0 is used).
 
-2. Update ``phpweb/include/version.inc`` (X_Y=major_minor release number):
+ 6. Check `./sapi/cli/php -v` output for version matching.
 
- a. ``$PHP_X_Y_VERSION`` to the correct version
+ 7. Tag the repository with the version f.e. `git tag -u YOURKEYID php-5.4.1`
 
- b. ``$PHP_X_Y_DATE`` to the release date
+ 8. Push the tag f.e. `git push origin php-5.4.1`.
 
- c. ``$PHP_X_Y_SHA256`` array and update all the SHA256 sums
+ 9. Run: `PHPROOT=. ./scripts/dev/makedist 5.4.1`, this will export the tag,
+    create configure and build three tarballs (gz, bz2 and xz). Check if the
+    pear files are updated (phar). On some systems the behavior of GNU tar can
+    default to produce POSIX compliant archives with PAX headers. As not every
+    application is compatible with that format, creation of archives with PAX
+    headers should be avoided. When packaging on such a system, the GNU tar can
+    be influenced by defining the environment variable
+    `TAR_OPTIONS='--format=gnu'`.
 
- d. set ``$PHP_X_Y_RC`` to false!
+10. Run `scripts/dev/gen_verify_stub <version> [identity]`, this will sign the
+    tarballs and output verification information to be included in announcement
+    email.
 
- e. Make sure there are no outdated "notes" or edited "date" keys in the
- ``$RELEASES[X][$PHP_X_VERSION]["source"]`` array
+11. Commit and push all the tarballs and signature files to
+    `web/php-distributions.git`, then update the git submodule reference in
+    `web/php.git`:
 
- f. Only for the first revision of a major or minor release bump
-    ``$PHP_X_VERSION``, ``$PHP_X_DATE`` and ``$PHP_X_RC_DATE``.
+    ```
+    git submodule init
+    git submodule update
+    cd distributions
+    git fetch
+    git pull --rebase origin master
+    cd ..
+    git commit distributions
+    git push
+    ```
 
-3. Create the release file (releases/x_y_z.php)
-   Usually we use the same content as for point 6, but included in php template
-   instead of the release xml.
+    This is to fetch the last commit id from php-distributions.git and commit
+    this last commit id to `web/php.git`, then, website will now sync.
 
-4. Update php-qa/include/release-qa.php and add the next version as an QARELEASE
-   (prepare for next RC)
+12. Once the release has been tagged, contact release managers, Windows
+    builders, and package maintainers so that they can build releases. Do not
+    send this announcement to any public lists.
 
-5. Update the ChangeLog file for the given major version
-f.e. ``ChangeLog-5.php`` from the NEWS file
+## Getting the stable release announced
 
- a. go over the list and put every element on one line
+ 1. Update `phpweb/include/releases.inc` with the old release info (updates the
+    download archives).
 
- b. check for &, < and > and escape them if necessary
+    * You can run `php bin/bumpRelease 7 2` where the first number is the major
+      version, and the second number is the minor version (7.2 in this example).
 
- c. remove all the names at the ends of lines
+    * If that fails for any non-trivially fixable reason, you can manually copy
+      the old information to `include/releases.inc`.
 
- d. for marking up, you can do the following (with VI):
+ 2. Update `phpweb/include/version.inc` (X_Y=major_minor release number):
 
-  I. ``s/^- /<li>/``
+    * `$PHP_X_Y_VERSION` to the correct version
+    * `$PHP_X_Y_DATE` to the release date
+    * `$PHP_X_Y_SHA256` array and update all the SHA256 sums
+    * Set `$PHP_X_Y_RC` to false!
+    * Make sure there are no outdated "notes" or edited "date" keys in the
+      `$RELEASES[X][$PHP_X_VERSION]["source"]` array.
+    * Only for the first revision of a major or minor release bump
+      `$PHP_X_VERSION`, `$PHP_X_DATE` and `$PHP_X_RC_DATE`.
 
-  II. ``s/$/<\/li>/``
+ 3. Create the release file (releases/x_y_z.php)
 
-  III. ``s/Fixed bug #\([0-9]\+\)/<?php bugfix(\1); ?>/``
+    Usually we use the same content as for point 6, but included in php template
+    instead of the release xml.
 
-  IV. ``s/Fixed PECL bug #\([0-9]\+\)/<?php peclbugfix(\1); ?>/``
+ 4. Update `php-qa/include/release-qa.php` and add the next version as an
+    QARELEASE (prepare for next RC).
 
-  V. ``s/FR #\([0-9]\+\)/FR <?php bugl(\1); ?>/``
+ 5. Update the ChangeLog file for the given major version
 
-  e. You may want to try php-web/bin/news2html to automate this task
+    f.e. `ChangeLog-7.php` from the `NEWS` file
 
-6. Add a short notice to phpweb stating that there is a new release, and
-highlight the major important things (security fixes) and when it is important
-to upgrade.
+    * Go over the list and put every element on one line.
+    * Check for `&`, `<` and `>` and escape them if necessary.
+    * Remove all the names at the ends of lines.
+    * For marking up, you can do the following (with `vi`):
 
- a. Call php bin/createNewsEntry in your local phpweb checkout
+        I. `s/^- /<li>/`
 
- b. Add the content for the news entry
+        II. `s/$/<\/li>/`
 
-7. Commit and push all the changes to their respective git repos
+        III. `s/Fixed bug #\([0-9]\+\)/<?php bugfix(\1); ?>/`
 
-8. **Check mirrors have been synced before announcing or pushing news**
-  Try, f.e. http://www.php.net/get/php-5.5.1.tar.bz2/from/a/mirror
-  Try several mirrors, mirrors may update slowly (may take an hour)
+        IV. `s/Fixed PECL bug #\([0-9]\+\)/<?php peclbugfix(\1); ?>/`
+
+        V. `s/FR #\([0-9]\+\)/FR <?php bugl(\1); ?>/`
+
+    * You may want to try `php-web/bin/news2html` to automate this task.
+
+ 6. Add a short notice to phpweb stating that there is a new release, and
+    highlight the major important things (security fixes) and when it is
+    important to upgrade.
+
+    * Call `php bin/createNewsEntry` in your local phpweb checkout.
+    * Add the content for the news entry.
+
+ 7. Commit and push all the changes to their respective git repos
+
+ 8. **Check website has been synced before announcing or pushing news**
+
+    Try, f.e. https://www.php.net/distributions/php-7.3.4.tar.xz
+
+    Website may update slowly (may take an hour).
+
+ 9. Please note down the sha256 and the PGP signature (.asc). These *must* be
+    included in the release mail.
 
-9. Please note down the sha256 and the PGP signature (.asc). These *must* be
-   included in the release mail.
 10. Wait an hour or two, then send a mail to php-announce@lists.php.net,
-php-general@lists.php.net and internals@lists.php.net with a text similar to
-http://news.php.net/php.internals/17222.
-Please make sure that the mail to php-announce@ is its own completely separate email.
-This is to make sure that replies to the announcement on php-general@ or internals@
-will not accidentally hit the php-announce@ mailinglist.
+    php-general@lists.php.net and internals@lists.php.net with a text similar to
+    http://news.php.net/php.internals/17222. Please make sure that the mail to
+    php-announce@ is its own completely separate email. This is to make sure
+    that replies to the announcement on php-general@ or internals@ will not
+    accidentally hit the php-announce@ mailinglist.
+
+## Re-releasing the same version (or -pl)
 
-Re-releasing the same version (or -pl)
---------------------------------------
+ 1. Commit the new binaries to `phpweb/distributions/`
 
-1. Commit the new binaries to ``phpweb/distributions/``
+ 2. Update `phpweb/include/version.inc` (X_Y=major_minor release number):
 
-2. Update ``phpweb/include/version.inc`` (X_Y=major_minor release number):
+    * If only releasing for one OS, make sure you edit only those variables.
+    * `$PHP_X_Y_VERSION` to the correct version
+    * `$PHP_X_Y_DATE` to the release date
+    * `$PHP_X_Y_SHA256` array and update all the SHA256 sums
+    * Make sure there are no outdated "notes" or edited "date" keys in the
+      `$RELEASES[X][$PHP_X_VERSION]["source"]` array.
 
- a. If only releasing for one OS, make sure you edit only those variables
+ 3. Add a short notice to phpweb stating that there is a new release, and
+    highlight the major important things (security fixes) and when it is
+    important to upgrade.
 
- b. ``$PHP_X_Y_VERSION`` to the correct version
+    * Call `php bin/createNewsEntry` in your local phpweb checkout.
+    * Add the content for the news entry.
 
- c. ``$PHP_X_Y_DATE`` to the release date
+ 4. Commit all the changes (`include/version.inc`, `archive/archive.xml`,
+    `archive/entries/YYYY-MM-DD-N.xml`).
 
- d. ``$PHP_X_Y_SHA256`` array and update all the SHA256 sums
+ 5. Wait an hour or two, then send a mail to php-announce@lists.php.net,
+    php-general@lists.php.net and internals@lists.php.net with a text similar to
+    the news entry.
 
- e. Make sure there are no outdated "notes" or edited "date" keys in the
- ``$RELEASES[X][$PHP_X_VERSION]["source"]`` array
+    Please make sure that the mail to php-announce@ is its own completely
+    separate email. This is to make sure that replies to the announcement on
+    php-general@ or internals@ will not accidentally hit the php-announce@
+    mailinglist.
 
-3. Add a short notice to phpweb stating that there is a new release, and
-highlight the major important things (security fixes) and when it is important
-to upgrade.
+## Forking a new release branch
 
- a. Call php bin/createNewsEntry in your local phpweb checkout
+ 1. One week prior to cutting X.Y.0beta1, warn internals@ that your version's
+    branch is about to be cut, and that PHP-X.Y will be moving into feature
+    freeze. Try to be specific about when the branch will be cut.
 
- b. Add the content for the news entry
+    Example: http://news.php.net/php.internals/99864
 
-4. Commit all the changes (``include/version.inc``, ``archive/archive.xml``,
-``archive/entries/YYYY-MM-DD-N.xml``)
+ 2. Just prior to cutting X.Y.0beta1, create the new branch locally.
 
-5. Wait an hour or two, then send a mail to php-announce@lists.php.net,
-php-general@lists.php.net and internals@lists.php.net with a text similar to
-the news entry.
-Please make sure that the mail to php-announce@ is its own completely separate email.
-This is to make sure that replies to the announcement on php-general@ or internals@
-will not accidentally hit the php-announce@ mailinglist.
+    Add a commit on master after the branch point clearing the `NEWS`,
+    `UPGRADING` and `UPGRADING.INTERNALS` files, updating the version in
+    `configure.ac` (run `./configure` to automatically update
+    `main/php_versions.h`, too) and `Zend/zend.h`. Also list the new branch in
+    `CONTRIBUTING.md`.
 
-Forking a new release branch
-----------------------------
+    Example: https://git.php.net/?p=php-src.git;a=commit;h=a63c99b
+    Push the new branch and the commit just added to master.
 
-1. One week prior to cutting X.Y.0beta1, warn internals@ that your version's branch
-   is about to be cut, and that PHP-X.Y will be moving into feature freeze.
-   Try to be specific about when the branch will be cut.
-      Example: http://news.php.net/php.internals/99864
+ 3. Immediately notify internals@ of the branch cut and advise the new merging
+    order. Example:
 
-2. Just prior to cutting X.Y.0beta1, create the new branch locally.
-   Add a commit on master after the branch point clearing the NEWS, UPGRADING
-   and UPGRADING.INTERNALS files, updating the version in configure.ac (run
-   ./configure to automatically update main/php_versions.h, too) and Zend/zend.h.
-   Also list the new branch in CONTRIBUTING.md.
-     Example: http://git.php.net/?p=php-src.git;a=commit;h=a63c99b
-   Push the new branch and the commit just added to master.
+    http://news.php.net/php.internals/99903
 
-3. Immediately notify internals@ of the branch cut and advise the new merging order:
-     Example: http://news.php.net/php.internals/99903
+ 4. Update php-web:git.php and https://wiki.php.net/vcs/gitworkflow to reflect
+    the new branch. Example:
 
-4. Update php-web:git.php and wiki.php.net/vcs/gitworkflow to reflect the new branch:
-     Example: https://github.com/php/web-php/commit/74bcad4c770d95f21b7fbeeedbd76d943bb83f23
+    https://github.com/php/web-php/commit/74bcad4c770d95f21b7fbeeedbd76d943bb83f23
 
-5. Notify nlopess@ to add PHP_X_Y tag to gcov.php.net
+ 5. Notify nlopess@ to add PHP_X_Y tag to gcov.php.net.
 
-Preparing for the initial stable version (PHP X.Y.0)
-----------------------------------------------------
+## Preparing for the initial stable version (PHP X.Y.0)
 
-1. About the time you release the first RC, remind the documentation team
-   (phpdoc@lists.php.net) to write the migration guide.  See to it that they
-   have done it before you release the initial stable version, since you want
-   to link to it in the release announcements.
+ 1. About the time you release the first RC, remind the documentation team
+    (phpdoc@lists.php.net) to write the migration guide. See to it that they
+    have done it before you release the initial stable version, since you want
+    to link to it in the release announcements.
 
-2. Timely get used to the differences in preparing and announcing a stable
-   release.
+ 2. Timely get used to the differences in preparing and announcing a stable
+    release.
 
-Prime the selection of the Release Managers of the next version
----------------------------------------------------------------
+## Prime the selection of the Release Managers of the next version
 
-1. About three months before the scheduled release of the first alpha of the
-   next minor or major release, issue a call for volunteers on 
-   internals@lists.php.net (cf. http://news.php.net/php.internals/98652).
+ 1. About three months before the scheduled release of the first alpha of the
+    next minor or major release, issue a call for volunteers on
+    internals@lists.php.net (cf. http://news.php.net/php.internals/98652).
 
-2. Make sure that there are two or more volunteers, and hold a vote if necessary
-   (see https://wiki.php.net/rfc/releaseprocess#release_managers_selection).
+ 2. Make sure that there are two or more volunteers, and hold a vote if
+    necessary (see
+    https://wiki.php.net/rfc/releaseprocess#release_managers_selection).
 
-3. Help the new release managers with their first steps.
+ 3. Help the new release managers with their first steps.
 
-New Release Manager Checklist
------------------------------
+## New Release Manager checklist
 
-1. Email systems@ to get setup for access to downloads.php.net and to be added to the
-   release-managers@ distribution list.
+ 1. Email systems@ to get setup for access to downloads.php.net and to be added
+    to the release-managers@ distribution list.
 
-2. Create a GPG key for your @php.net address and publish it by editing `include/gpg-keys.inc`
-   in the `web-php` repository, adding the output of `gpg --fingerprint "$USER@php.net"`. Let
-   one or more of the previous RMs sign your key. Publish your public key to pgp.mit.edu with:
-   `gpg --keyserver pgp.mit.edu --send-keys $KEYID`
+ 2. Create a GPG key for your @php.net address and publish it by editing
+    `include/gpg-keys.inc` in the `web-php` repository, adding the output of
+    `gpg --fingerprint "$USER@php.net"`. Let one or more of the previous RMs
+    sign your key. Publish your public key to pgp.mit.edu with:
+    `gpg --keyserver pgp.mit.edu --send-keys $KEYID`
 
-3. Request karma to edit main/php_version.h and Zend/zend.h. Possibly karma for other restricted parts of
-   php-src might come in question. To edit main/php_version.h in a release branch,
-   you need release manager karma in global_avail.
+ 3. Request karma to edit `main/php_version.h` and `Zend/zend.h`. Possibly karma
+    for other restricted parts of php-src might come in question. To edit
+    `main/php_version.h` in a release branch, you need release manager karma in
+    `global_avail`.
 
-4. Request karma for web/qa.git and web/php.git for publishing release announcements.
+ 4. Request karma for `web/qa.git` and `web/php.git` for publishing release
+    announcements.
 
-5. Request moderation access to php-announce@lists.php.net and primary-qa-tester@lists.php.net lists, to
-   be able to moderate your release announcements. All the announcements should be sent from
-   the @php.net alias.
+ 5. Request moderation access to php-announce@lists.php.net and
+    primary-qa-tester@lists.php.net lists, to be able to moderate your release
+    announcements. All the announcements should be sent from the @php.net alias.