From d094ca83df2d57dd782884c23cabdc9a5d282ce8 Mon Sep 17 00:00:00 2001
From: Peter Kokot <peterkokot@gmail.com>
Date: Mon, 8 Jul 2019 23:28:02 +0200
Subject: [PATCH] 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
---
docs/release-process.md | 103 ++++++++++++++++++++++------------------
1 file changed, 58 insertions(+), 45 deletions(-)
diff --git a/docs/release-process.md b/docs/release-process.md
index 46b0107763..b7c5cb953b 100644
--- a/docs/release-process.md
+++ b/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 git@git.php.net: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 `primary-qa-tester@lists.php.net` 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 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.
+ 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.
--
2.40.0