Por qué me importa este tema ahora
Sin el ritual de leer notes, el laboratorio empieza a vivir de rumores. Cada nota de release es un posible marcador de superficie. Enseño alfabetización del calendario de features — no a copiar mi matriz interna.
La ruta es simple y aburrida — por eso funciona: Chrome → Firefox → WebKit, luego contraste con BCD.
Marco público (enlaces)
- Chrome release notes
- Firefox Releases
- WebKit blog
- MDN BCD
Qué observo en el lab, en palabras simples
La ruta
Primero la línea Chromium como mi instrumento principal. Luego Gecko como matriz de control. Luego WebKit, para no olvidar el universo paralelo de Safari. BCD es contraste de calendario, no juez.
No apunto «todo», sino lo que cambia el piso de capacidades de la superficie. Los párrafos de marketing se los dejo al marketing.
Preview vs stable
Lo que brilla en trial/preview es peligroso como piso de versión. Lo marco como hipótesis de futuro, no como norma del etalon de hoy. Si no, el feature-floor empieza a vivir en un borrador de release que el usuario aún no tiene.
Vínculo con BCD
Las notes dan el relato. BCD da la tabla. El runtime da el hecho. Tres fuentes — tres roles. Mezclar roles es una forma de equivocarse con seguridad.
Qué cambia esto en detect y/o en el build (sin detalles)
Las hipótesis sobre la superficie reciben fecha y enlace. Las discusiones se acortan. Los experimentos empiezan menos veces con «creo que esto ya está disponible para todos».
Qué no diré y por qué
No convierto las notes en una lista secreta de marcadores de detect ni publico mi matriz de combate.
Conclusión breve en primera persona
Las release notes son la higiene semanal del laboratorio dual. Sin ellas pronto empiezo a detectar el año pasado.
