Catch up with current procedures

- Git is used for moving existing extensions to PECL
- PHP versions with the PHP 7.4 examples
- Some minor tweaks here and there
- Mention re2c also
- Mention Docker image as a helper tool

Author: petk

docs/release-process.md

@@ -37,34 +37,43 @@
 
     Moving extensions from php-src to PECL:
 
-    * Checkout the pecl directory, most likely you want a sparse-root checkout
+    * Ask someone with Git admin access to create a new empty repository on
+      https://git.php.net under the PECL projects and a belonging GitHub mirror.
 
-        ```
-        svn co --depth=empty https://svn.php.net/repository/pecl
+    * Clone a new copy of the php-src repository (it will rewrite history, keep
+      contributors commits and include only the extension folder):
+
+        ```sh
+        git clone https://git.php.net/repository/php-src.git ext-name
+        cd ext-name
+        git filter-branch --prune-empty --subdirectory-filter ext/ext-name master
         ```
 
-    * Create a directory for the extension including branch and tag structure,
-      no trunk at this point and commit this to svn
+    * Set remote Git push URL for the PECL extension:
 
-      ```
-      cd pecl; mkdir foo foo/tags foo/branches; svn add foo; svn commit
-      ```
+        ```sh
+        git remote set-url origin [email protected]:pecl/category/ext-name
+        ```
 
-    * Move the extension from php-src to the new location
+    * Create branch and tags structure appropriate for the extension and push:
 
-      ```
-      svn mv https://svn.php.net/repository/php/php-src/trunk/ext/foo \
-      https://svn.php.net/repository/pecl/foo/trunk
-      ```
+        ```sh
+        git push -u origin master
+        ```
 
     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
 
-    For moving extensions from PECL to php-src the svn mv has to be done the
-    other way round.
+    For moving extensions from PECL to php-src the procedure needs to go through
+    the RFC process and a new Git commit without rewriting the php-src Git
+    commit history.
+
+ 8. There is a PHP release Docker image https://github.com/sgolemon/php-release
+    with forks available to help releasing.
 
 ## Rolling a non stable release (alpha/beta/RC)
 
@@ -76,42 +85,43 @@
  3. Run the `scripts/dev/credits` script in php-src and commit the changes in
     the credits files in ext/standard.
 
- 4. Checkout the release branch for this release (e.g., PHP-5.4.2) from the main
+ 4. Checkout the release branch for this release (e.g., PHP-7.4.2) from the main
     branch.
 
  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"`
+    beta. Do not use dashes, you should `#define PHP_VERSION "7.4.22RC1"` and
+    not `#define PHP_VERSION "7.4.22-RC1"`
 
- 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).
+ 6. Compile and run `make test`, with and without ZTS, using the right Bison and
+    re2c version (for PHP 7.4, minimum Bison 3.0.0 and re2c 0.13.4 are used).
 
  7. Check `./sapi/cli/php -v` output for version matching.
 
  8. If all is right, commit the changes to the release branch:
 
-    ```
+    ```sh
     git commit -a
     ```
 
  9. Tag the repository release branch with the version, e.g.:
 
-    ```
-    git tag -u YOURKEYID php-5.4.2RC2
+    ```sh
+    git tag -u YOURKEYID php-7.4.2RC2
     ```
 
 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
+    `configure.ac` and `NEWS` in the *main* branch (PHP-7.4 for example) to
+    prepare for the **next** version. F.e. if the RC is "7.4.1RC1" then the new
+    one should be `7.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.
 
 11. Push the changes to the main repo, the tag, the main branch and the release
-    branch:
+    branch. Release branches for alpha/beta/.0RCx releases before to GA release
+    don't need to be pushed (a local temporary branch should be used).
 
-    ```
+    ```sh
     git push --tags origin HEAD
     git push origin {main branch}
     git push origin {release branch}
@@ -139,15 +149,16 @@
 
  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.
+    releases and RCs are configured here. Only `$QA_RELEASES` needs to be
+    edited.
 
-    Example: When rolling an RC, set the 'rc' with appropriate information for
+    Example: When rolling an RC, set the `rc` with appropriate information for
     the given version.
 
     Note: Remember to update the sha256 checksum information.
 
  2. 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):
+    (e.g. announce 7.4.0RC1, but not 7.4.1RC1):
 
     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
@@ -159,9 +170,9 @@
 
     * Add the content for the news entry. Be sure to include the text:
 
-      ```
-      "THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION!"
-      ```
+        ```text
+        "THIS IS A DEVELOPMENT PREVIEW - DO NOT USE IT IN PRODUCTION!"
+        ```
 
  3. Commit and push changes to qa and web.
 
@@ -181,7 +192,7 @@
     setup as a moderator for `[email protected]` by having someone
     (Hannes, Dan, Derick) run the following commands for you:
 
-    ```
+    ```sh
     ssh lists.php.net
     sudo -u ezmlm ezmlm-sub ~ezmlm/primary-qa-tester/mod moderator-email-address
     ```
@@ -194,7 +205,7 @@
 
  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
+    7.2, merge to 7.3, 7.4 etc...). Then you can cherry-pick it in your release
     branch. Don't forget to update `NEWS` manually in an extra commit then.
 
  3. Commit those changes. Ensure the tests at
@@ -203,8 +214,8 @@
  4. Run the `scripts/dev/credits` script in php-src and commit the changes in
     the credits files in ext/standard.
 
- 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).
+ 5. Compile and run `make test`, with and without ZTS, using the right Bison and
+    re2c version (for PHP 7.4, minimum Bison 3.0.0 and re2c 0.13.4 are used).
 
  6. Check `./sapi/cli/php -v` output for version matching.
 
@@ -229,7 +240,7 @@
     `web/php-distributions.git`, then update the git submodule reference in
     `web/php.git`:
 
-    ```
+    ```sh
     git submodule init
     git submodule update
     cd distributions
@@ -252,8 +263,8 @@
  1. Update `phpweb/include/releases.inc` with the old release info (updates the
     download archives).
 
-    * 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).
+    * You can run `php bin/bumpRelease 7 4` where the first number is the major
+      version, and the second number is the minor version (7.4 in this example).
 
     * If that fails for any non-trivially fixable reason, you can manually copy
       the old information to `include/releases.inc`.
@@ -263,12 +274,12 @@
     * `$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
-    * `$PHP_X_Y_TAGS` array should include 'security' if this is a security
+    * `$PHP_X_Y_TAGS` array should include `security` if this is a security
       release
     * Make sure there are no outdated "notes" or edited "date" keys in the
       `$RELEASES[X][$PHP_X_VERSION]["source"]` array.
 
- 3. Create the release file (releases/x_y_z.php)
+ 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.
@@ -308,7 +319,7 @@
 
  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
+    Try, f.e. https://www.php.net/distributions/php-7.4.0.tar.xz
 
     Website may update slowly (may take an hour).
 
@@ -428,4 +439,6 @@
 
  5. Request moderation access to [email protected] and
     [email protected] lists, to be able to moderate your release
-    announcements. All the announcements should be sent from the @php.net alias.
+    announcements. All the announcements should ideally be sent from the
+    @php.net alias. Note, that for sending emails as @php.net alias a custom
+    SMTP server needs to be used.