# An SVN Commit Succeeding Is Not Users Receiving the Update ## Claim A successful SVN commit for a WordPress.org plugin release says nothing about whether users can update yet, because distribution now waits on a roughly six-hour cooldown plus an automated security review the author does not control or see in advance. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Changes what "shipped" means in my release checklist: the verification step has to query the distributed version, not the commit. - The review dependency is on Jetpack Scan, which makes plugin distribution depend on a commercial service's availability and verdict. - A block is possible and the author has no advance visibility, so a time-critical security release needs the cooldown budgeted into the plan. - The cooldown figure is as published in the announcement and worth re-checking, since it is the kind of number that changes quietly. ## Evidence From the Make WordPress Plugins post by David Perez announcing automated security review for plugin releases, with a six-hour cooldown and automatic blocking. ## Links - [[A Readme-Only Commit Can Register as a Release]] — the other half of the same workflow change — what triggers a release, and when it reaches anyone - [[Patch Coverage Is a Distribution Problem Not a Code Problem]] — the same gap between a fix existing and a fix arriving - [[Trust Granted at Admission Must Be Re-Verified at Every Update]] — the security rationale this pipeline implements - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — the release-and-distribution thread this operational change belongs to.