Notas de versiones del navegador para equipos web
Convierte las notas del navegador en comprobaciones de compatibilidad, decisiones de despliegue y evidencia de alternativas.
Quieres la documentación estructurada de Plataforma?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
Las notas de versión son señales de cambio, no certificados de compatibilidad. Úsalas para elegir una investigación acotada y verifica después capacidad, permisos, alternativa y resultado visible.
Leer la señal
Consulta las notas de Chrome y las notas de Firefox. Registra canal, versión, fecha, función, bandera, requisito de origen y migración. Distingue entrega, experimento, advertencia y retirada.
Una nota describe implementación, no el límite de la tarea ni la finalización del servidor. Identifica una página propia, datos sintéticos, resultado visible y alternativa antes de probar.
Elegir la matriz
Elige versión estable, candidata y una versión anterior soportada según la política del producto. Cada celda debe indicar si es evidencia de estándar, capacidad en tiempo de ejecución o recorrido de aplicación.
Registra versión, origen, contexto seguro, permisos, fixture y resultado esperado. Un fallo puede pertenecer al navegador, a la aplicación, a la infraestructura o a un servicio externo.
Tabla de decisión
| Observación | Decisión | Resultado visible | Límite |
|---|---|---|---|
| Nota coincide y candidato pasa | desplegar gradualmente | conservar ruta y alternativa | versión declarada |
| Función usa bandera o experimento | mantener alternativa | explicar indisponibilidad | política |
| Método ausente o contexto bloqueado | no forzar | ofrecer alternativa | página actual |
| Llamada rechazada | clasificar una vez | mostrar recuperación | navegador |
| Llamada resuelta | verificar aplicación | confirmar señal visible | navegador y aplicación |
Fixture de fallo
El fixture crea controles, simula la superficie propia, comprueba la rama visible y elimina nodos en finally. No cambies una huella ni uses credenciales.
async function probar() {
const h = document.createElement('div');
h.innerHTML = '<p id="estado"></p><button id="alternativa" hidden>Usar alternativa</button>';
document.body.append(h);
const estado = h.querySelector('#estado');
const alternativa = h.querySelector('#alternativa');
try {
const ok = typeof navigator.share === 'function';
const r = ok
? await navigator
.share({ title: 'Prueba sintética', url: '/fixture' })
.then(() => 'completo')
.catch(() => 'fallo')
: 'ausente';
estado.textContent = r === 'completo' ? 'Completado' : 'Usa la alternativa';
if (r !== 'completo') alternativa.hidden = false;
console.assert(estado.textContent && (r === 'completo' || !alternativa.hidden));
return r;
} finally {
h.remove();
}
}
Despliegue y reversión
Registra versión, función, alcance, aserciones, responsable y condición de reversión. Verifica un acuse de la aplicación, no solo una promesa resuelta. Comprueba etiquetas, foco, teclado y mensajes.
Reversa ante excepción elevada, foco atrapado, alternativa ausente o acuse de servidor perdido. Conserva la nota original, la salida de prueba y el resultado visible.
Mantenimiento y BotBrowser
BotBrowser puede ofrecer contextos controlados para recorridos autorizados de candidatos y comprobaciones repetibles. No garantiza la interpretación de notas, no concede permisos, no sustituye conformidad ni prueba finalización del servidor. La documentación de aislamiento demuestra repetibilidad, no una garantía universal.
Mantén un registro con fuente, versión, estado, alternativa, resultado y próxima revisión sin datos personales. Consulta también la guía de compatibilidad de APIs y la guía WPT.
Clasifica cada cambio por impacto y enlázalo con un fixture y una aserción visible.
Registra flags, certificados, contexto y estado del perfil para comparar candidatos de forma justa.
Separa la llamada del navegador del acuse de la aplicación y conserva el primer fallo.
Revisa la matriz después de cada actualización y elimina candidatos solo con una decisión explícita.
La ficha debe responder qué cambió, qué versiones afectan, cómo se detecta, qué ve la persona y cuál es la siguiente acción.
Prueba presencia y fallo para una API nueva, ruta predeterminada y alternativa para una bandera retirada.
La fecha del proveedor no es la fecha de preparación de tu aplicación; registra responsable y evidencia.
Un registro útil cubre cambio, versiones, detección, resultado visible y siguiente acción.
Compara el build exacto y el contexto: banderas, certificados, políticas y red pueden variar entre equipos.
Separa llamada del navegador, estado visible y acuse del servidor antes de decidir el despliegue.
Revisa la ficha después de actualizaciones y conserva responsable y fecha de caducidad para excepciones.
Relaciona cada retirada, cambio predeterminado o política de seguridad con una prueba positiva y una ruta bloqueada explicada.
El cierre debe indicar si el cambio está listo, en fase, aplazado o revertido y enlazar su evidencia y responsable.
Si falta evidencia, marca la decisión como pendiente con responsable, dato faltante y fecha siguiente.
El traspaso termina cuando otra persona puede repetir la decisión, ver la misma alternativa y conocer qué evidencia la cambiaría.
Mantén la nota breve para la revisión, pero separa claramente navegador y aplicación.
Usa el mismo vocabulario de evidencia en cada versión: candidato, detectado, visible, confirmado, pendiente y revertido.
Así el revisor distingue qué límite se observó y cuál permanece abierto.
Esta distinción mantiene útil la decisión sin exagerar la compatibilidad.
Mantén el alcance explícito.
La decisión conserva esta frontera.
Fuentes
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.