A corrected PHP candidate deserves a new artifact identity
PHP skipped RC1 after an extension API numbering mistake. A new candidate identity keeps test evidence traceable without treating automation as the problem.
By 
Paul. Architecture and infrastructure
Looking back from November 2026 at the week of 23 September, PHP's missing RC1 offers a concrete argument for preserving artifact identity. When a candidate has been tagged with incorrect compatibility metadata, correcting it under a new identity keeps later test reports intelligible. Silently substituting different contents beneath the old identity would make agreement about what was tested harder. Release automation should validate the compatibility transition and preserve the distinction between the failed candidate and its correction.
In his 23 September account, release manager Daniel Scherzer explains that automation scheduled API-number updates for the wrong branch-creation stage. The tagged RC1 therefore carried incorrect numbers. The maintainers corrected them and created RC2. The PHP notice of 24 September calls RC2 the first release candidate and explicitly describes it as an early test version unsuitable for production. The unusual numbering records a correction; it does not establish production compromise or stable-release readiness.
Compatibility is part of the artifact
The release-manager account names ZEND_EXTENSION_API_NO, ZEND_MODULE_API_NO and PHP_API_VERSION. These identifiers matter to the contract between the runtime and extensions. The automation moved their update to creation of the later release branch instead of the first candidate's minor-version branch. The failure was therefore about a transition and its compatibility metadata. A successful sequence of packaging commands could still produce the wrong candidate if the transition's required state was not expressed correctly.
For a team maintaining software with native extensions, that distinction changes what a release check should establish. Producing an archive is one outcome; establishing that it advertises the intended contract is another. The artifact includes both executable behavior and the metadata by which other software recognizes compatibility. A check focused solely on whether a file exists or can be unpacked leaves that contract outside its scope. The useful question is whether the resulting candidate has the identity and compatibility state intended for this point in the release cycle.
This is a recommendation about release design, rather than a claim that every project needs PHP's exact identifiers. Another ecosystem can encode the same relationship differently. What transfers is the need to identify which values distinguish the maintenance branch from continuing development and when those values must change. A transition deserves its own assertion because ordinary repeated releases may never exercise it. Repetition can make a procedure look reliable while the infrequent branch boundary remains insufficiently checked.
Test reports need a stable referent
A release identifier gives people a shared object to discuss. If one tester reports a failure against an early candidate and another reports success against its correction, different names make the distinction visible. Reusing the earlier name for changed contents would require extra evidence to reconstruct which artifact each tester received. Checksums can help distinguish bytes, but preserving a separate candidate identity also makes the correction understandable in ordinary release communication and issue triage.
That clarity has a business cost attached to it. Someone interpreting a test report needs to decide whether to investigate, reproduce or disregard it as belonging to a superseded candidate. Ambiguity consumes that person's time and can lead to a mistaken readiness decision. A skipped number is usually simpler to explain than conflicting reports that appear to refer to the same build. This is an inference about traceability, not a measured claim about time saved by PHP's maintainers.
The same reasoning applies to records inside a business's own release process. An acceptance decision should identify the candidate on which the evidence was collected. Correcting the artifact afterward creates a new question about the validity of that evidence. Even if the correction seems small, the team needs a clear relationship between the old observation and the new artifact. Distinct candidate identities let that relationship be discussed explicitly instead of making it depend on memory or informal messages.
Automation remains a sound choice
The strongest objection is that adding manual supervision can also fail. Scherzer expressly says automation was legitimate and that he reviewed the code without spotting this issue. His account supports improving the transition checks, not blaming the use of a container or replacing every scripted step with a checklist. A person can miss a state transition just as a script can encode it incorrectly. Repetition alone does not turn either approach into evidence that the resulting compatibility contract is right.
A proportionate response would retain useful automation while making the important invariant visible. The review can ask whether the candidate branch and continuing development advertise the intended relationship after the split. That is more concrete than a general instruction to be careful. Manual review can still contribute judgment, particularly for unusual transitions, but it should have a defined fact to inspect. The objective is a correct, identifiable candidate rather than a ritual preference for either manual or automated work.
There are limits to this lesson. It does not establish that every rebuilding operation needs a new public marketing version. Internal build systems can distinguish artifacts in other explicit ways. Nor does the account support an allegation of an attack, or a conclusion that RC2 was safe for live customers. The official testing warning remains necessary. Correct identity makes evidence traceable; it does not supply the missing acceptance evidence for a production release.
In software maintenance, preserve that distinction when agreeing release responsibilities. Define the compatibility facts that must hold at branch transitions and keep corrected candidates distinguishable from earlier ones. PHP's skipped number made a specific correction visible. A release process earns confidence when its names let the next maintainer tell exactly which artifact a result describes.