No PHP 8.6.0RC1

Tomorrow, the PHP 8.6 release manager team is planning to announce the first release candidate (RC) of PHP 8.6, PHP 8.6.0RC2. So, what happened to PHP 8.6.0RC1?

Automation

The process of tagging new PHP releases is fairly mechanical. The documentation lists the commands to run and what changes need to be made to various files. In an effort to simplify the process for release managers (RMs), there have been repeated attempts over the years to automate some of the steps.

For PHP 8.6, I am serving as the "veteran" RM and mentoring two "rookie" RMs (Matteo Beccati and Joe Ferguson), both of whom have been using a Docker container to automate part of the process of building new releases. To be clear, there is nothing wrong with using such automation, and I'm not trying to call them out for doing something wrong. I had reviewed the code that they were using and also did not spot the issue that arose this week.

Version bump

When the first release candidate for a PHP branch is created (in this case PHP 8.6.0RC1), the release managers also create a new branch for that minor version (here PHP 8.6). At that point, the primary branch in the php/php-src is prepared for developing the next minor version. For example, last year when I was building PHP 8.5.0RC1 I pushed a commit to update the main branch to be targeting PHP 8.6.

One of the steps when creating this new development branch is to update the API numbers in ZEND_EXTENSION_API_NO, ZEND_MODULE_API_NO, and PHP_API_VERSION. We want those numbers in the version branch (e.g. PHP-8.5) to be higher than the previous numbers in the primary branch, and we want the primary branch to have even higher numbers. Thus, we ensure that the PHP 8.5 branch has a newer API version than it had while under development, and that PHP 8.6 development has a newer version than PHP 8.5.

Unfortunately, the script that the release managers are using for automation this year had a bug. It was designed to bump those numbers in the PHP-8.6 branch when creating the PHP-8.6.0 branch (which is part of building the last release candidate) rather than when creating the PHP-8.6 branch as part of building the first release candidate.

Because the API numbers were not bumped at the right time, the code that was tagged as php-8.6.0RC1 had the wrong API numbers. As a result, a new tag needed to be created once the API numbers were properly bumped. The "first" release candidate of PHP 8.6.0 will therefore be numbered 2 instead of 1.

Conclusion

The PHP 8.6 release managers have been great to work with, and have been diligent in their supervision of the automation that they use. Everyone makes mistakes, and they are far from the first to need to skip a planned release number.

My goal here is simply to explain what happened for anyone looking for PHP 8.6.0RC1, not to criticize or cast blame on the release managers for PHP 8.6. Matteo and Joe handled the situation the exact same way that I would have. They built the RC1 tag, realized that the version bump was missing, and decided to tag a new RC2, all without me needing to intervene.

In a field where "first" is frequently translated to "number 0", hopefully translating "first release candidate" to "release candidate number 2" shouldn't be too confusing.