Saltar al contenido principal

Política de versionado

Traducción Beta No Oficial

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

Esta página describe la política de versionado que seguimos para el paquete react-native.

Probamos exhaustivamente cada versión de React Native, tanto con pruebas manuales como automatizadas, para garantizar que la calidad no retroceda.

El canal stable de React Native sigue la política de lanzamientos 0.x.y descrita a continuación.

React Native también ofrece un canal de lanzamientos nightly para fomentar comentarios tempranos sobre características experimentales.

Esta página describe nuestro enfoque para los números de versión de react-native y los paquetes bajo el ámbito @react-native.

Versiones estables​

React Native lanza versiones estables con una cadencia regular.

Seguimos el esquema de versionado 0.x.y:

  • Los cambios importantes se publicarán en una nueva versión menor, es decir, incrementamos el número x (ej.: de 0.78.0 a 0.79.0).

  • Las nuevas funcionalidades y APIs también se publicarán en una nueva versión menor, es decir, incrementamos el número x (ej.: de 0.78.0 a 0.79.0).

  • Las correcciones de errores críticos se publicarán en una nueva versión de parche, es decir, incrementamos el número y (ej.: de 0.78.1 a 0.78.2).

Los lanzamientos estables se publican regularmente, con la última versión etiquetada como latest en NPM.

Una serie de lanzamientos bajo el mismo número menor se denomina serie menor (ej. 0.76.x es la serie menor para 0.76.0, 0.76.1, 0.76.2, etc.).

Puedes leer más sobre nuestro compromiso con la estabilidad en la página de lanzamientos.

Cambios importantes​

Los cambios importantes son inconvenientes para todos, y nos esforzamos por minimizarlos al máximo. Todos los cambios importantes incluidos en cada lanzamiento estable se destacarán en:

Para cada cambio importante, nos comprometemos a explicar su justificación, proporcionar una API de reemplazo cuando sea posible y minimizar el impacto en los usuarios finales.

¿Qué se considera un cambio importante?​

Consideramos un cambio importante para React Native:

  • Cambios incompatibles en las APIs (es decir, una API modificada o eliminada que impide compilar/ejecutar tu código). Ejemplos:

    • Modificaciones en APIs JS/Java/Kotlin/Obj-c/C++ que requieran cambios en tu código para compilar.
    • Cambios en @react-native/codegen sin compatibilidad con versiones anteriores.

  • Cambios significativos en comportamiento/tiempo de ejecución. Ejemplo:

    • La lógica de diseño de una propiedad (prop) cambia drásticamente.

  • Cambios significativos en la experiencia de desarrollo. Ejemplo:

    • Eliminación completa de una funcionalidad de depuración.

  • Actualizaciones mayores en dependencias transitivas. Ejemplos:

    • Actualizar React de 18.x a 19.x
    • Actualizar el Target SDK en Android de 34 a 35).

  • Reducción de versiones soportadas de plataformas. Ejemplos:

    • Incrementar el min SDK en Android de 21 a 23
    • Incrementar la versión mínima de iOS a 15.1.

No consideramos importantes los siguientes cambios:

  • Modificaciones en APIs con prefijo unstable_: Estas APIs exponen características experimentales cuya forma final no está definida. Al usar el prefijo unstable_, podemos iterar más rápido y estabilizar las APIs antes.

  • Cambios en APIs privadas o internas: Estas APIs suelen tener prefijos como internal_, private_ o estar ubicadas en carpetas/paquetes internal/ o private/. Aunque algunas sean públicamente visibles debido a limitaciones de herramientas, no las consideramos parte de nuestra API pública, por lo que las modificaremos sin previo aviso.

    • De igual forma, si accedes a nombres de propiedades internas como __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED o __reactInternalInstance$uk43rzhitjg, no hay garantías. Lo haces bajo tu propio riesgo.
    • Las clases anotadas con @FrameworkAPI también se consideran internas.

  • Cambios en APIs de herramientas/desarrollo: Algunas APIs públicas de React Native están reservadas para integraciones con frameworks y otras herramientas. Por ejemplo, ciertas APIs de Metro o React Native DevTools están diseñadas solo para uso de frameworks o herramientas. Los cambios en estas APIs se discuten directamente con las herramientas afectadas y no se consideran cambios importantes (no los comunicaremos ampliamente en las publicaciones de lanzamiento).

  • Advertencias de desarrollo: Como las advertencias no afectan el comportamiento en tiempo de ejecución, podemos agregar nuevas o modificar las existentes en cualquier versión.

Si anticipamos que un cambio causará problemas generalizados en la comunidad, haremos todo lo posible para proporcionar una ruta de migración gradual para el ecosistema.

Ciclos de desaprobación​

Mientras seguimos desarrollando y evolucionando React Native, creamos nuevas APIs y a veces necesitamos desaprobar las existentes. Estas APIs pasarán por un ciclo de desaprobación.

Una vez que una API está desaprobada, permanecerá disponible también durante los siguientes lanzamientos estables.

Por ejemplo: si una API se desaprueba en React Native 0.76.x, seguirá disponible en 0.77.x y no se eliminará antes de React Native 0.78.x.

A veces decidimos mantener una API desaprobada por más tiempo si consideramos que el ecosistema necesita más tiempo para migrar. Para estas APIs generalmente proporcionamos advertencias que ayudan a los usuarios a migrar.

Canales de lanzamiento​

React Native depende de una próspera comunidad de código abierto para reportar errores, abrir pull requests y enviar RFCs. Para fomentar comentarios, admitimos varios canales de lanzamiento.

nota

Esta sección será más relevante para desarrolladores que trabajen en frameworks, bibliotecas o herramientas de desarrollo. Los desarrolladores que usan React Native principalmente para crear aplicaciones de usuario no deberían preocuparse por otros canales además de latest.

latest​

latest contiene lanzamientos estables de React Native que siguen semver. Es lo que obtienes al instalar React Native desde npm. Este es el canal que ya estás usando hoy. Las aplicaciones de usuario que consumen React Native directamente usan este canal.

Publicamos regularmente nuevas series menores de React Native y actualizamos la etiqueta latest para reflejar la última versión estable.

next​

Antes de declarar estable un nuevo lanzamiento de React Native, publicamos una serie de candidatos a lanzamiento (RC), comenzando desde RC0. Estas versiones son pre-lanzamientos (siguiendo el esquema de versiones 0.79.0-rc.0) y se etiquetan como next en NPM.

Cuando se crea una nueva rama y se empiezan a publicar RCs en NPM y GitHub, es buen momento para probar tu biblioteca/framework con una versión next de React Native.

Esto asegurará que tu proyecto seguirá funcionando correctamente con las próximas versiones de React Native.

Sin embargo, no uses pre-lanzamientos/RCs directamente en aplicaciones de usuario, ya que no se consideran listos para producción.

nightly​

También publicamos un canal nightly. Las versiones nightly se publican diariamente desde la rama main de facebook/react-native. Se consideran versiones inestables de React Native y no se recomiendan para uso en producción.

Las versiones nightly siguen el esquema de versionado 0.80.0-nightly-<DATE>-<SHA>, donde <DATE> es la fecha del nightly y <SHA> es el SHA del commit utilizado para publicarlo.

Las versiones nightly se proporcionan únicamente con fines de prueba, y no garantizamos que el comportamiento permanezca constante entre ellas. No siguen el protocolo semver que empleamos para los lanzamientos de latest/next.

Es recomendable configurar un flujo de CI para probar tu biblioteca contra react-native@nightly diariamente, asegurando así que seguirá funcionando con futuros lanzamientos.