Two-Week Browsers and the Dated Test Binary

The browser your tests drive is not the browser your users run, and what has kept that gap tolerable is the speed at which it opens. From the Edge release of 27 August, three vendors have that speed at two weeks instead of four. The version list a QA plan tracks gets longer. What an end-to-end suite certifies does not change at all. The gap between those two facts is the whole subject.

Three vendors have published two-week Stable schedules, and the first of them takes effect on 27 August. Google set the change out on the Chrome for Developers blog on 3 March: Chrome's Stable channel drops from four weeks to two beginning with Chrome 153 on 8 September, while Extended Stable keeps its eight-week cycle. Microsoft's published release schedule makes Edge 152 — in Stable as of 27 August — the version the two-week cadence starts from, with Edge 153 due the week of 10 September and Extended Stable likewise unchanged at eight weeks. Mozilla posted the same plan to dev-platform on 9 July: Firefox 155 on 1 September, with an explicit note that the team will monitor how the change works in practice and adjust if needed. Of those three dates only Edge's falls on 27 August; the Chrome and Firefox changes are scheduled for the first half of September. What is on record the day Edge 152 lands is three published schedules rather than a run of shipped two-week releases. The schedules are enough. They change something on your side of the release, in the binary your tests actually drive.

A green end-to-end run is not a certificate about a browser; it is a certificate about one build on one day. It says the application behaved correctly against one specific binary — that parser, that layout engine, that particular set of features shipped, unshipped and half-enabled behind flags. The binary was not chosen by you, and the mechanism is documented. Playwright's documentation states it directly: each version of Playwright needs specific versions of browser binaries to operate, it updates those versions with every release, and every Playwright upgrade may require re-running the install command. Puppeteer has the same shape, downloading a specific Chrome for Testing build so that its API is guaranteed to work out of the box. The build under test is therefore a downstream consequence of a dependency version somebody else cut, on a date somebody else chose. Everything past that one sentence — works on Stable, works for your users, will still work next month — is inference the reader supplies rather than evidence the run produced.

How long that certificate stays worth anything is a function of the interval. On a four-week cycle, a pin left untouched for twelve weeks ended three majors behind Stable; on a two-week cycle the same twelve weeks cost six. The binary was already dated on the day it was pinned, because the runner's release necessarily precedes the pin, and halving the interval doubles the rate at which that distance grows from there. The early-warning channel does not double with it. Chrome's post keeps each Beta three weeks ahead of its Stable, an interval sized for a four-week cycle. At two weeks that puts two betas in flight simultaneously, and the pre-release channel you were meant to rehearse against begins overlapping itself. Rehearsal that used to mean one version ahead now means choosing which of two.

The other end of the range holds still. Extended Stable stays on an eight-week major cycle in both Chrome's and Edge's published schedules — Edge's table has 152 arriving there on 27 August and 156 next, in the week of 22 October. ESR is defined by not moving. A WebView embedded in a native application updates when the operating system or the app store says so, a schedule with no relationship to any of the above. Halve the interval at the fast end, hold the slow end fixed, and the spread between your fastest and slowest real client widens on its own, with no decision of yours involved. The certified build sits at one point in that widening band. What it proved does not change — one build, one day, still true — but the fraction of your sessions it describes gets smaller every fortnight, and there is no run you can add to the suite that reverses that.

The standard objection is that evergreen browsers retired version planning years ago: clients auto-update, the modal user is current, and matrices belong to the IE era. That describes the median consumer, and of him it has been broadly true. Your client distribution is a different object. Version pinning survives wherever the update is somebody's decision rather than a background task — Extended Stable fleets and ESR estates are one form, corporate images with update rings and a change-control board a second, embedded WebViews a third. Then there is the one teams forget, because it does not belong to a customer at all: the test runner in your own CI is a pinned browser that you chose, installed, and stopped thinking about. Evergreen concentrated version planning into the places where a human still signs off. One of those places is a lockfile you maintain.

That leaves two ways to hold the pin, each with its own failure. Track the fast channel and the suite re-baselines every fortnight: browser upgrades arrive inside dependency bumps on a vendor's calendar rather than yours, some red runs are genuine regressions and some are the runner's own churn, and the two are indistinguishable until somebody reads them. Pin and hold, and the signal is stable precisely because it stopped tracking anything: drift accumulates in silence, and the first report of a Stable-channel behaviour change arrives from a user. Both branches leave the same sentence at the bottom of the run, and it is shorter than the word passed suggests — this application worked against this build, on this date. On a four-week cycle the distance between that sentence and what people read into it was survivable. At two weeks it opens faster than the sprint that produced the run can close. Print the build string and the date beside the result, and the suite goes back to claiming only what it can demonstrate.