1.4.4: outlier filter on by default for new installs
Soak feedback from an 18-day production run on cwv 1.0.1 surfaced a 596876ms FCP beacon (9.9 minutes, from a backgrounded-tab artefact) landing in storage and dragging the metric's p75 around. The outlier filter that catches this class of event already shipped in 1.1.0 with per-metric thresholds, but was opt-in. The opt-in posture was deliberate at 1.1.0 to avoid silently shifting distributions for existing operators on upgrade, but that argument doesn't apply to new installs.
1.4.2: CI hygiene release (all-green for the first time)
Follow-up to 1.4.1. No functional change. Addresses three CI jobs (phpstan, phpcs, cspell) that had been silently failing under the d.o. CI template's allow_failure: true defaults on every pipeline since 1.0.0. The "passed with warnings" badge had been treated as green; it isn't. 1.4.2 is the first release on this project where every CI job is genuinely success without allow-failure crutches.
Five separate findings from a 1.4.0 code-review pass and a 1.4.0 field-test pass on a real-traffic site, folded into one tag rather than 1.4.1 and 1.4.2 back to back. Three are critical bugs that 1.4.0 shipped with — recommended upgrade for all 1.4.0 adopters. The other two are hardening that pays off accumulated debt.
No schema changes. No new config keys. No update hook. Drop-in upgrade from 1.4.0.
The first minor release after 1.0.0 stable. Bundles three operator-experience features driven by 1.0.0 production-soak feedback, the four 1.0.1 correctness fixes, and roughly twenty smaller items from a full code-review pass of the 1.0.0 codebase. No contract changes; the alpha7 collector contract that was frozen at beta1 remains stable.
The first minor release after 1.0.0 stable. Bundles three operator-experience features driven by 1.0.0 production-soak feedback, the four 1.0.1 correctness fixes, and roughly twenty smaller items from a full code-review pass of the 1.0.0 codebase. No contract changes; the alpha7 collector contract that was frozen at beta1 remains stable.
Patch release driven by an in-tree code-review pass on the 1.0.0 codebase. Three correctness bugs and one documentation correction. Recommended upgrade for all 1.0.0 adopters; required upgrade for any deployment fronted by a shared cache (LSCache, Varnish, Cloudflare full-page) where the request-ID corruption on cached responses was actively poisoning async-decorator data.
The first stable release of cwv. Promoted directly from 1.0.0-beta1 after 10 days of clean production soak on a real-traffic site (71 beacons captured at 10% sampling, zero bugs surfaced). The standard rc1 ladder is skipped because the soak window already provided the evidence rc1 was designed to gather. Honest about the choice: operators who require strict rc-then-stable progression for compliance reasons should treat the 10-day production-soak result as the equivalent.
The first beta of cwv. Freezes the collector contract for the entire 1.x line and lands the production-readiness hardening pass on the public beacon endpoint. From this release forward, sibling-module authors can build collectors against a stable contract; cwv can be recommended for production deployment alongside the operator-side guidance documented in the new SECURITY.md and PERFORMANCE.md files.
1.0.0-alpha10: render-tree collector and panel-weight tightening
Second content release built on the alpha7 collector contract. Same architectural shape as alpha9's backend cache instrumentation: implements async-decoration plus panel-contribution, opt-in via a new config key, zero overhead when disabled. Validates that adding a new correlation axis is a focused, repeatable pattern against a stable contract.
The first content release built on the alpha7 collector contract. Surfaces backend cache health (Memcache, Redis, APCu, database, file backends) per request and correlates it with Core Web Vitals metrics on a new admin panel. Validates the "one collector per minor release" cadence the contract was designed around.
Two showstopper bugs surfaced by alpha7 field testing on a real LSCache-fronted Drupal 11 site. Neither required architectural rework; both are one-line fixes against the alpha7 substrate. No contract changes, no new features.
Architectural release. Reframes cwv from "real-user CWV with cache visibility" to a Drupal-aware correlation substrate where cache state is one of many backend signal axes. The contract defines four collector shapes that, together, cover every collection case anticipated for the lifetime of the 1.x line. Frozen at beta1 and lived with for years.
This is a bug-fix release driven by alpha4 field testing on an LSCache-fronted Drupal 11 site. The cache-state stamping pattern introduced in alpha4 is fundamentally incompatible with response caching, so the cache HIT vs MISS comparison panel (alpha4's lead diagnostic) never populates on any site that uses an external cache. Alpha5 fixes the underlying mechanism so the diagnostic actually works.
The data foundation release. Alpha4 turns cwv from "captures CWV correctly" into "answers operator questions about why pages are slow." Three deliverables, all designed against real data captured in alpha1-alpha3 field testing on a production-shape Drupal site.
Diagnostic surfaces on /admin/reports/cwv
The report page is now five panels, with the Cache HIT vs MISS comparison as the lead diagnostic:
Tiny but consequential release. Alpha2's LCP over-reporting fix was correct in code but operationally undeliverable to existing-install browsers because the cache-busting URL parameter didn't change between alpha1 and alpha2. Alpha3 fixes that. Recommended upgrade for any 1.0.0-alpha2 user.
Bug fix release driven by alpha1 field testing on a real Drupal site. Three issues fixed; recommended upgrade for any 1.0.0-alpha1 user because the LCP fix corrects data-correctness issues that would have skewed any aggregation built on alpha1 data.
First release of CWV — real-user Core Web Vitals tracking with backend correlation. Self-hosted end-to-end: bundled JavaScript using PerformanceObserver, in-Drupal beacon endpoint, custom database table. No external services.
