Summary
atmosphere.php declares two version sources that have drifted:
- Plugin header
Version: 1.1.0 (atmosphere.php:6)
- Code constant
\define( 'ATMOSPHERE_VERSION', '1.0.0' ); (atmosphere.php:22)
WordPress reads the header for plugin-update / activation flows, so users see 1.1.0. Code that branches on ATMOSPHERE_VERSION (and consumers that compare it across releases) sees 1.0.0 indefinitely.
Why it matters downstream
FOSSE bundles Atmosphere and uses ATMOSPHERE_VERSION as the cache key for the one-time activation shim that calls Atmosphere\activate() (which flush_rewrite_rules()). When the constant stops moving, the shim believes "we already activated this version" and skips the flush on a real upgrade. If a future Atmosphere release changes the well-known rewrite rule (or adds a new one), bundled consumers stay on the stale rewrite map until something else triggers a flush.
That risk has been pre-existing, but it just got more load-bearing for FOSSE — Automattic/fosse#170 deletes FOSSE's parallel /.well-known/atproto-did handler and now depends entirely on Atmosphere's rewrite + template_redirect registration.
Suggested change
Bump ATMOSPHERE_VERSION to '1.1.0' to match the header, and consider asserting they stay in lockstep — e.g., a composer validate-style script that reads atmosphere.php's Version: header and the constant and fails on mismatch.
If there's a reason the constant intentionally lags the header (semantic-versioning-ish releases vs. internal bump?), I'd love to know so FOSSE can re-tune its activation shim.
Related
Summary
atmosphere.phpdeclares two version sources that have drifted:Version: 1.1.0(atmosphere.php:6)\define( 'ATMOSPHERE_VERSION', '1.0.0' );(atmosphere.php:22)WordPress reads the header for plugin-update / activation flows, so users see
1.1.0. Code that branches onATMOSPHERE_VERSION(and consumers that compare it across releases) sees1.0.0indefinitely.Why it matters downstream
FOSSE bundles Atmosphere and uses
ATMOSPHERE_VERSIONas the cache key for the one-time activation shim that callsAtmosphere\activate()(whichflush_rewrite_rules()). When the constant stops moving, the shim believes "we already activated this version" and skips the flush on a real upgrade. If a future Atmosphere release changes the well-known rewrite rule (or adds a new one), bundled consumers stay on the stale rewrite map until something else triggers a flush.That risk has been pre-existing, but it just got more load-bearing for FOSSE — Automattic/fosse#170 deletes FOSSE's parallel
/.well-known/atproto-didhandler and now depends entirely on Atmosphere's rewrite +template_redirectregistration.Suggested change
Bump
ATMOSPHERE_VERSIONto'1.1.0'to match the header, and consider asserting they stay in lockstep — e.g., acomposer validate-style script that readsatmosphere.php'sVersion:header and the constant and fails on mismatch.If there's a reason the constant intentionally lags the header (semantic-versioning-ish releases vs. internal bump?), I'd love to know so FOSSE can re-tune its activation shim.
Related