php/archived-php-src
1
0
Fork 0
mirror of https://github.com/php/php-src.git synced 2026-03-24 00:02:20 +01:00
Code Issues Packages Projects Releases Wiki Activity

release-process: update based on recent 8.5 releases and discussions (#19939)

Browse Source
This commit is contained in:
Daniel Scherzer
2026-02-16 21:43:10 -08:00
committed by GitHub
parent 0b4fbf2e70
commit af69d3a0f2
1 changed files with 65 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

86
docs/release-process.md
View File

@@ -6,6 +6,7 @@ repository available according to the release schedule.
The release schedule for each version is published on the
[PHP wiki](https://wiki.php.net):
- [PHP 8.5](https://wiki.php.net/todo/php85)
- [PHP 8.4](https://wiki.php.net/todo/php84)
- [PHP 8.3](https://wiki.php.net/todo/php83)
- [PHP 8.2](https://wiki.php.net/todo/php82)
@@ -137,14 +138,23 @@ slightly different steps. We'll call attention where the steps differ.
> During the first RC release, you will create (and push!) the version
> branch for the pre-GA release, e.g., `PHP-8.2`. See
> "[Forking a new version branch](#forking-a-new-version-branch)" below.
> From this point forward, all pre-GA release branches will be created from
> For the last RC release, and the subsequent GA release, follow the post-GA
> procedure, but until that point, pre-GA release branches will be created from
> this version branch. Again, these release branches are local-only. Do not
> push them!
>
> ```shell
> git checkout -b php-X.Y.0beta2-local-release-branch upstream/PHP-X.Y
> git checkout -b php-X.Y.0RC3-local-release-branch upstream/PHP-X.Y
> ```
> 💬 **Hint** \
> The *patch-level version branch* for GA (PHP X.Y.0) is created as part of the
> last *planned* RC release (currently PHP X.Y.0RC4). After the last RC is released,
> additional bug fixes in the PHP X.Y branch will not be a part of PHP X.Y.0. If a regression
> is found that warrants including a fix in PHP X.Y.0, use the same process as
> for other patch releases - merge the patch as normal to PHP X.Y, and then cherry-pick
> the patch to the patch-level PHP X.Y.0 branch.
> 🔷 **Non-stable version branches: post-GA** \
> After GA, you will create (and push) a new *patch-level version branch*
> along with each non-stable release. For example, if you are building a
@@ -263,7 +273,7 @@ slightly different steps. We'll call attention where the steps differ.
The NEWS is updated at the *start* of the cycle for the next tag, e.g.
[Update NEWS for PHP 8.2.0 alpha2][] was sent as part of tagging 8.2.0 alpha **1**.
🔷 **For post-GA releases only,** switch back to the *version branch* for
🔷 **For post-GA releases, and the final pre-GA RC** switch back to the *version branch* for
your release (e.g., `PHP-8.2`) and bump the version numbers in
`main/php_version.h`, `Zend/zend.h`, `configure.ac` and `NEWS`. This prepares
the version branch for the next version.
@@ -291,11 +301,19 @@ slightly different steps. We'll call attention where the steps differ.
> Only release tags should have version numbers in these files that do not
> end in `-dev` (e.g., `8.1.7`, `8.1.7RC1`, `8.2.0alpha1`, etc.).
10. Push the changes to the `php-src`.
Do not forget to merge up PHP-X.Y all the way to master. When resolving
the conflicts, ignore the changes from PHP-X.Y in higher branches. It
means using something like `git checkout --ours .` when on PHP.X.Y+1 or
master after the merge resulting in the conflicts.
Be sure to set up a merge driver for the NEWS file as described in
the [Git FAQ page on the PHP wiki][gitfaq-mandatory].
11. Push the changes to the `php-src`.
```shell
git push upstream php-X.Y.ZRCn # tag name
git push upstream PHP-X.Y.Z # patch-level version branch (post-GA only)
git push upstream PHP-X.Y.Z # patch-level version branch (beginning with the last RC before GA)
git push upstream PHP-X.Y # version branch (post-branch creation only)
git push upstream master # version branch (pre-branch creation only)
```
@@ -306,12 +324,7 @@ slightly different steps. We'll call attention where the steps differ.
>
> Local-only release branches should not be pushed!
Do not forget to merge up PHP-X.Y all the way to master. When resolving
the conflicts, ignore the changes from PHP-X.Y in higher branches. It
means using something like `git checkout --ours .` when on PHP.X.Y+1 or
master after the merge resulting in the conflicts.
11. Run the following using the release tag to export the tree, create the
12. Run the following using the release tag to export the tree, create the
`configure` script, and build and compress three tarballs (`.tar.gz`,
`.tar.bz2` and `.tar.xz`).
@@ -319,7 +332,7 @@ slightly different steps. We'll call attention where the steps differ.
./scripts/dev/makedist php-X.Y.ZRCn
```
12. Run the following using the release tag and your GPG key ID to sign the
13. Run the following using the release tag and your GPG key ID to sign the
tarballs and save the signatures to `php-X.Y.ZRCn.manifest`, which you can
upload to GitHub and include in the announcement emails.
@@ -327,7 +340,7 @@ slightly different steps. We'll call attention where the steps differ.
./scripts/dev/gen_verify_stub X.Y.ZRCn YOURKEYID > php-X.Y.ZRCn.manifest
```
13. If you have the [GitHub command line tool][] installed, run the following to
14. If you have the [GitHub command line tool][] installed, run the following to
create a public Gist for the manifest file:
```shell
@@ -336,7 +349,7 @@ slightly different steps. We'll call attention where the steps differ.
Or you may go to https://gist.github.com to create it manually.
14. Copy the tarballs (using scp, rsync, etc.) to your `public_html/` folder on
15. Copy the tarballs (using scp, rsync, etc.) to your `public_html/` folder on
downloads.php.net.
```shell
@@ -347,10 +360,10 @@ slightly different steps. We'll call attention where the steps differ.
> If you do not have a `public_html` directory, create it and set its
> permissions to `0755`.
15. Now the tarballs and signatures may be found at
16. Now the tarballs and signatures may be found at
`https://downloads.php.net/~yourname/`, e.g. https://downloads.php.net/~derick/.
16. Once the release is tagged, contact the release-managers@php.net distribution
17. Once the release is tagged, contact the release-managers@php.net distribution
list so that Windows binaries can be created. Once those are made, they may
be found at https://windows.php.net/qa/.
@@ -519,8 +532,8 @@ slightly different steps. We'll call attention where the steps differ.
> 💬 **Hint** \
> You should have created this branch when packaging the non-stable release
> candidate for this version. If it is for a PHP-X.Y.0 version, then just
> create and push this branch.
> candidate for this version. If it is for a PHP-X.Y.0 version, then the branch
> was created as part of the final planned release candidate, PHP-X.Y.0RC4.
2. If a CVE commit needs to be merged to the release, have it committed to
the base branches and [merged upwards as usual][] (e.g. commit the CVE fix
@@ -938,13 +951,20 @@ feature development that cannot go into the new version.
See [Prepare for PHP 8.2][] and [Prepare for PHP 8.2 (bis)][] for an example
of what this commit should include.
4. Push the new version branch and the changes to the `master` branch, with an
> 💬 **Hint** \
> The API version numbers in `Zend/zend_extensions.h`, `Zend/zend_modules.h`, and
> `main/php.h` in `master` need to be **greater** than the ones in the new `PHP-X.Y`
> branch. Generally, use the `YYYYMMDD` date for the *Thursday* as the value for the
> `PHP-X.Y` API numbers, and for the *Friday* as the value for the `master` API
> numbers. This ensures that `master` is always considered newer than the version branch.
5. Push the new version branch and the changes to the `master` branch, with an
appropriate commit message (e.g., "master is now for PHP 8.3.0-dev").
5. Immediately notify internals@ of the new branch and advise on the new merging
6. Immediately notify internals@ of the new branch and advise on the new merging
order. For example: https://news-web.php.net/php.internals/99903
6. Update `web-php:git.php` and https://wiki.php.net/vcs/gitworkflow to reflect
7. Update `web-php:git.php` and https://wiki.php.net/vcs/gitworkflow to reflect
the new branch.
For example:
@@ -959,6 +979,29 @@ feature development that cannot go into the new version.
> minor improvements and bug fixes. All major improvements and new features must
> wait.
8. Most CI configuration is maintained on the lowest supported branch; update the
applicable files there to reflect the branch cut, and then upmerge that commit
5 times to get it to `master`. The following files need to be updated:
* `.github/nightly_matrix.php` (add new branch, update version for `master`)
[Updating after 8.5 branch cut](https://github.com/php/php-src/commit/197921a8aa7b2f9af103b439bf913e23d6ed1b98)
* `.github/scripts/windows/find-target-branch.bat` (update version for `master`)
[Updating after 8.5 branch cut](https://github.com/php/php-src/commit/107075605db6f1b15ce275e345d1c6de04a464b0)
9. Update the `.github/workflows/push.yml` file with the new branch. This file
does not need to be updated on the lowest supported branch; just update the
newly cut branch to add the new branch to the branches that the workflow
runs on (and then upmerge once to `master`). For example:
* [Updating after 8.5 branch cut](https://github.com/php/php-src/commit/77af4780ccbbc96a2f85a3102d45a15f5e26f9c9)
10. Update the version of `php/php-sdk-binary-tools` used for the `master` branch for the `nightly`
and `push` jobs to account for the new version; this can be done before the branch cut if
the new version is ready. If the new version is not ready when the branch is cut, file an
issue reporting the problem. For example:
* [Updating after 8.5 branch cut](https://github.com/php/php-src/commit/f7e39a91d5a9de53fc4e184f6fce6116ca3388a1)
## Preparing for the initial stable version (PHP X.Y.0)
@@ -1167,5 +1210,6 @@ volunteers to begin the selection process for the next release managers.
[GPG key]: https://en.wikipedia.org/wiki/GNU_Privacy_Guard
[Generating a new GPG key]: https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key
[sign your GPG key]: https://carouth.com/articles/signing-pgp-keys/
[gitfaq-mandatory]: https://wiki.php.net/vcs/gitfaq#mandatory_git_settings
[Send emails from a different address or alias]: https://support.google.com/mail/answer/22370?hl=en
[security-txt]: https://github.com/php/policies/blob/main/security-policies.rst#making-changes-to-securitytxt