Why this topic matters to me now
Without a ritual of reading notes, the lab starts living on rumors. Every release note is a potential surface marker. I teach feature-calendar literacy — not copying my internal matrix.
The route is simple and boring — which means it works: Chrome → Firefox → WebKit, then check against BCD.
Public frame (links)
- Chrome release notes
- Firefox Releases
- WebKit blog
- MDN BCD
What I observe in the lab, in plain words
The route
First the Chromium line as my main instrument. Then Gecko as a control matrix. Then WebKit, so I do not forget Safari’s parallel universe. BCD is a calendar check, not a judge.
I do not write down “everything” — only what changes the surface capability floor. Marketing paragraphs I leave to marketing.
Preview vs stable
What lights up in trial/preview is dangerous as a version floor. I mark it as a future hypothesis, not as today’s baseline norm. Otherwise the feature-floor starts living in a release draft the user does not have yet.
Link to BCD
Notes give the story. BCD gives the table. Runtime gives the fact. Three sources — three roles. Mixing roles is a way to be confidently wrong.
What this changes in detect and/or the build (no specifics)
Surface hypotheses get a date and a link. Arguments get shorter. Experiments less often start from “I think this is already available to everyone.”
What I will not say, and why
I do not turn notes into a secret list of detect markers and do not publish my combat matrix.
Short first-person takeaway
Release notes are weekly hygiene for the dual lab. Without them I quickly start detecting last year.
