You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here is what happened. Composer and Packagist have no way to flag a version as broken, so when a release turns out to be faulty, which is rare, my practice is to withdraw it: it is removed from the release notes and from the linear history, and the fix ships as the next patch version. 4.2.1 was such a release; 4.2.2 superseded it.
The tag itself was supposed to stay so that lock files and exact pins keep resolving. It was deleted by mistake during a cleanup of my repositories, and I have restored it, pointing at the same commit as before. Projects installing from a lock file were not affected, since Composer downloads by commit hash; only an exact 4.2.1 constraint was hit.
Activity
dg commentedon Oct 26, 2026
Here is what happened. Composer and Packagist have no way to flag a version as broken, so when a release turns out to be faulty, which is rare, my practice is to withdraw it: it is removed from the release notes and from the linear history, and the fix ships as the next patch version. 4.2.1 was such a release; 4.2.2 superseded it.
The tag itself was supposed to stay so that lock files and exact pins keep resolving. It was deleted by mistake during a cleanup of my repositories, and I have restored it, pointing at the same commit as before. Projects installing from a lock file were not affected, since Composer downloads by commit hash; only an exact
4.2.1constraint was hit.brendt commentedon Oct 27, 2026
Thanks for the clarification! For future reference, Packagist advices to simply tag the next patch release and keep the faulty release.