Saltar al contenido principal
Creemos que el control de versiones es una parte fundamental de nuestra oferta y trabajamos para proporcionar un esquema de control de versiones coherente para nuestros productos, de modo que nuestros usuarios puedan gestionar y prever cómo afectarán nuestros cambios a su uso.

​
Control de versiones semántico

El control de versiones semántico (también conocido como semver) es una estrategia de control de versiones cuya principal característica es hacer detectables los cambios no compatibles. Una versión se compone de 3 números separados por puntos: ... Por ejemplo, 2.12.5, 0.1.0 y 10.5.35 son números semver válidos.
  • El primer número representa un cambio mayor: la API de la biblioteca ha cambiado de una forma no compatible con versiones anteriores. Cuando se incrementa la parte major de una versión, la API pública de esa biblioteca ha cambiado. Por ejemplo, el código y la funcionalidad marcados anteriormente como obsoletos se eliminan de la base de código.
  • El segundo número representa un cambio menor: se ha añadido nueva funcionalidad a la API de la biblioteca o se ha marcado como obsoleta, manteniendo la compatibilidad con versiones anteriores. Se espera que la nueva versión minor sea segura para su uso y animamos a los clientes a actualizar. Sin embargo, como es imposible conocer todas las formas en que los clientes usan un componente, siempre existe la posibilidad de que los cambios afecten al uso actual del componente. Por lo tanto, recomendamos verificar y probar antes de realizar una actualización.
  • El tercer número representa un cambio de parche: se ha corregido un error y no debería tener ningún impacto en la API expuesta a los usuarios. Debería ser seguro actualizar, pero siempre se recomienda hacer pruebas.

​
Uso en producción

Auth0 proporciona enlaces a nuestra red de distribución de contenido (CDN), donde alojamos algunas de nuestras bibliotecas. La forma en que hagas referencia a un componente en tu código determinará si los cambios se incorporan automáticamente y cuándo lo harán. Por ejemplo, si enlazas una versión principal desde un script y se publica una nueva versión secundaria, recibirás la actualización en cuanto se lance. Recomendamos esta práctica para entornos de desarrollo y para experimentar con Auth0. A continuación, se muestran ejemplos de cómo incrustar los archivos fuente: 
<!-- versión mayor -->
<script src="https://cdn.auth0.com/example/1/library.js"></script>

<!-- versión menor -->
<script src="https://cdn.auth0.com/example/1.0/library.js"></script>

<!-- versión de parche (recomendada para producción) -->
<script src="https://cdn.auth0.com/example/1.0.1/library.js"></script>
Cuando los componentes de Auth0 se despliegan en producción, recomendamos a nuestros usuarios fijar una versión exacta y realizar pruebas exhaustivas con esa versión. Aunque añadir nuevas funciones de forma retrocompatible no debería afectar a su código, las interacciones con el comportamiento del componente pueden ser difíciles de predecir. Incluso correcciones de errores triviales pueden introducir cambios en las suposiciones que usted hacía sobre el componente y que podrían dejar de ser válidas. Cada componente de código abierto de Auth0 que siga semver tendrá una etiqueta correspondiente a una versión publicada en su repositorio de git. Como algunos proyectos usan las herramientas de npm para publicar versiones, las etiquetas tendrán la letra v como prefijo. Por ejemplo, la etiqueta de la versión 5.2.3 será v5.2.3.

​
Más información