Versión estable y preparación para 1.0
0.1.0-rc.3 ya está publicado. La siguiente decisión es si su alcance documentado y no experimental está listo para 0.1.0, sin requerir todas las funciones de la hoja de ruta. La revisión 1.0 a continuación es una decisión de compatibilidad separada, no un aumento automático de la versión. Un pequeño número de issues abiertas no es un criterio de aceptación.
Lo que se ha entregado
Las bases y propuestas de la hoja de ruta original (#43 y #46–#63), las convenciones de creación opcionales (#88–#92), los trabajo de datos de ruta y Suspense (#118–#119), el estilo/visibilidad de pestañas (#122–#123) y la experiencia de navegación rc.3 (#117 y #133–#138) completaron el alcance definido en sus issues. Las issues de investigación cerradas documentan los resultados de la investigación, no una API de producción universal.
El mapa de capacidades Capacidades nativas y opciones de contenedores explica a los propietarios reales de la plataforma. La guía de compatibilidad Alcance y compatibilidad de RC define la API congelada y enumera las funciones que siguen siendo experimentales. En particular, al cerrar el prototipo de transición predictiva Android no se publicó su implementación upstream de Core.
Criterios de publicación
| Criterio | Evidencia requerida para la decisión de publicación | Registro actual |
|---|---|---|
| Alcance de la API | Congelar la API no experimental documentada; documentar cualquier corrección incompatible y su migración en un nuevo candidato | RC alcance |
| Artefacto reproducible | Versión npm exacta y archivo de bloqueo, sin alias de enrutador local ni parche Core no publicado; construir y ejecutar un consumidor en iOS y Android | Aceptación del consumidor #152 |
| Comportamiento nativo | Empujar/reemplazar/atrás, gestos cancelados, guards, resultados modales, stacks retenido y eliminación pasan la matriz nativa totalmente compatible en la commit de la release | Informe de contrato nativo y artefactos de CI |
| Accesibilidad y preferencias | Grabar teclado, texto grande, sistema Reducir movimiento y comprobaciones físicas del lector de pantalla; identificar resultados hablados/manuales por separado de las afirmaciones automáticas | Informe de accesibilidad, #152 |
| Defectos conocidos | Resolver defectos que bloquean la publicación en el alcance prometido; para límites de plataforma/upstream, registrar la reproducción, versiones afectadas, composición admitida y una disposición explícita del mantenedor | Dirección heredada #139 |
| Documentación | EN/pt-BR/es/zh-CN los ejemplos coinciden con las API exportadas; instalación, propiedad, límites experimentales y migración/límites conocidos son accesibles desde la ruta de aprendizaje | Primera aplicación, compatibilidad, capacidades |
| Publicación | CI y las suites nativas completas tienen éxito en la misma commit de la release; el tarball final pasa las comprobaciones de instalación nueva; el mantenedor aprueba la publicación | Validación de liberación |
Un candidato anterior con pruebas aprobadas aporta evidencia de esa revisión; no exime de validar un commit de release diferente. La cobertura de hardware faltante permanece sin verificar hasta que el mantenedor la pruebe o la acepte explícitamente como una limitación documentada. Un pase de dispositivo beta iOS complementa, en lugar de reemplazar, la línea base del simulador compatible. Ningún período de uso o recuento de descargas por sí solo demuestra que está preparado.
Seguimientos y decisiones de investigación
- #139: se aísla la causa Core y NativeScript #11587 propone la corrección. PR #160 registra la validación nativa. El Core 9.1.3 publicado todavía está afectado. Espere una corrección publicada, actualice la dependencia y vuelva a ejecutar la matriz de consumidor/nativa, o limite explícitamente la composición admitida antes de tomar una decisión de lanzamiento.
- #152: el informe del consumidor publicado informe de validación registra la salida física del servicio VoiceOver y el procedimiento/resultados del emulador TalkBack por separado de las aserciones de la interfaz de usuario. El hardware Android no está disponible; el mantenedor aceptó la validación del emulador con ese límite. Lea los límites del habla y los gestos antes de tratar esto como una certificación de accesibilidad amplia.
- #145: la propuesta de observación v1 registra la evidencia del ciclo de vida nativo y la decisión de mantener el adaptador privado. La falta de identificadores de entrada autoritativos y la mutación de destino simultánea no admitida impiden un controlador público. El progreso continuo de UIKit y un adaptador Jolt permanecen fuera de los requisitos de versión estable.
- #64: mantiene la hoja de ruta como un índice del alcance entregado y los seguimientos actuales, no como una lista de verificación que promueve silenciosamente integraciones experimentales a estables.
La entrega adicional puede permanecer en los candidatos cuando una solución cambia el comportamiento o la API congelada. Una vez que los criterios anteriores tengan evidencia y el mantenedor acepte los límites documentados restantes, publique 0.1.0 a través del flujo de trabajo de lanzamiento. Una decisión posterior 1.0.0 necesita su propio compromiso de compatibilidad de API y experiencia en aplicaciones; no se sigue de agotar la lista de cuestiones.
Revisión para 1.0 — 2026-10-25
Aún no está listo para publicar 1.0. La API tiene evidencia sustancial de implementación y aceptación nativa, pero un PR de documentación fusionada o un paquete de vista previa ascendente no es un candidato de lanzamiento con las dependencias finales.
| Área | Resultado de la revisión | Acción restante |
|---|---|---|
| Puntos de entrada públicos | Se revisó la entrada raíz, cinco entradas de enrutamiento de archivos, la entrada de búsqueda del sistema y la exportación de metadatos del paquete. Se agregaron las siete referencias de exportación con nombre que faltaban a la guía API. | Apruebe el compromiso de compatibilidad 1.x a continuación. |
| Comportamiento documentado | Se documentan guards, resultados, entradas retenidas, stacks con nombre, eliminación y propiedad de la plataforma. Las integraciones experimentales siguen identificadas explícitamente. | Revalidar cualquier comportamiento modificado por la actualización de dependencia final. |
| El defecto conocido | #139 se reproduce en el Core publicado; La solución propuesta se verifica en un caso de reproducción aislado. | Adopte y valide una versión publicada corregida de Core o excluya explícitamente la composición afectada. |
| Consumidor y accesibilidad | #152 registra el consumidor rc.3 exacto, el VoiceOver físico y el emulador TalkBack. Los límites de hardware/gestos siguen siendo explícitos. | Lleve esos límites a las notas de la versión; Vuelva a ejecutar la aceptación relevante en el artefacto de lanzamiento. |
| Documentación e idiomas | Inglés, portugués, español y chino simplificado comparten las mismas rutas de guía y ejemplos de código. | Comprueba la cobertura de idiomas, los enlaces y los anclajes; La cobertura de idiomas no es una garantía de nueva plataforma. |
| Publicación | El flujo de trabajo valida el tarball y la matriz nativa completa antes de la publicación. | Ejecútelo con la commit seleccionado para la release y obtenga la aprobación del mantenedor. |
Compromiso de compatibilidad 1.x propuesto
- Las importaciones públicas son las entradas declaradas en
package.json#exports, sus valores/tipos documentados y los contratos componentes de Vue. Los archivos presentes ensrc/odist/no crean importaciones profundas admitidas. - La compatibilidad estable incluye opciones predeterminadas, fallas/resultados de navegación, ordenamiento de guard, propiedad/ciclo de vida de las entradas y comportamiento de la plataforma compatible, no solo nombres de funciones.
- Experimental significa que la característica tiene un límite de soporte/evidencia más estrecho. Antes de 1.0, elija si desea conservar esa API para 1.x o moverla detrás de un nuevo contrato opcional con versión explícita. No interrumpa silenciosamente una exportación raíz existente en una versión menor simplemente porque su guía dice experimental.
- Los cambios incompatibles en el contrato estable requieren una versión principal y orientación para la migración. Los cambios adicionales y las correcciones compatibles se pueden enviar en versiones menores o de parche. Esta revisión no ha eliminado ni promocionado ninguna API.
- No se requiere ningún modo drawer adicional, controlador DevTools en vivo, adaptador Jolt o prototipo predictivo simplemente para completar la hoja de ruta. Un nuevo caso de uso de una aplicación puede justificar un trabajo separado.
La evidencia de revisión informe de validación registra la revisión, verificaciones y limitaciones de la fuente. Esta revisión no autoriza la publicación ni afirma que cada API exportada tenga una nueva validación en hardware.