Passer au contenu principal
Nous pensons que la gestion de versions est un élément crucial de notre offre. Nous mettons tout en œuvre pour proposer un schéma de gestion de versions pour nos produits afin d’aider nos utilisateurs à gérer et prévoir l’incidence des modifications sur l’utilisation.

​
Gestion de versions sémantique

La gestion de versions sémantique (également appelée « semver ») est une stratégie de gestion de versions dont la principale caractéristique est de rendre publiques les modifications majeures. Une version se compose de trois chiffres séparés par des points : ... Par exemple : 2.12.5, 0.1.0 et 10.5.35 sont des numéros de version semver valides.
  • Le premier numéro représente une modification majeure : l’API de la bibliothèque a été modifié de manière définitive. Lorsque la majeure partie d’une version est modifiée, l’API publique de cette bibliothèque l’est aussi. Par exemple, le code et les fonctionnalités précédemment marqués comme étant déconseillés sont retirés de la base de code.
  • Le deuxième numéro représente un modification mineure : de nouvelles fonctionnalités sont ajoutées ou déconseillées de l’API de la bibliothèque, tout en conservant une compatibilité descendante. La nouvelle version mineure est censée pouvoir être utilisée en toute sécurité et nous encourageons nos clients à effectuer la mise à jour. Toutefois, comme il est impossible de savoir comment les clients utilisent un composant, il y a toujours un risque que les changements aient une incidence sur l’utilisation actuelle du composant concerné. Par conséquent, nous recommandons de procéder à un essai avant d’effectuer une mise à jour.
  • Le troisième numéro représente un correctif : un bogue a été corrigé et cela ne devrait pas avoir d’incidence sur l’API utilisée. La mise à jour est censée être sans risque, mais il est toujours préférable de procéder à des essais.

​
Utilisation en environnement de production

Auth0 fournit des liens vers notre Réseau de fourniture de contenu (CDN) où nous mettons à disposition certaines de nos bibliothèques. La manière dont vous faites référence à un composant dans votre code aura une incidence quant à la prise en compte automatique des modifications et au moment où elles surviennent. Ainsi, si vous créez un lien vers la version majeure à partir d’un script et qu’il existe une nouvelle version mineure, vous recevrez la mise à jour dès qu’elle sera publiée. Nous encourageons cette pratique pour les environnements de développement et pour la mise à l’essai d’Auth0. Voici des exemples d’intégration des fichiers source : 
<!-- major release -->
<script src="https://cdn.auth0.com/example/1/library.js"></script>

<!-- minor release -->
<script src="https://cdn.auth0.com/example/1.0/library.js"></script>

<!-- patch release (recommended for production) -->
<script src="https://cdn.auth0.com/example/1.0.1/library.js"></script>
Lorsque les composants Auth0 sont déployés en production, nous encourageons nos utilisateurs à adopter une version complète et à tester minutieusement l’utilisation de cette version. Bien que l’ajout de nouvelles fonctionnalités en respectant la compatibilité descendante ne devrait pas casser votre code, les interactions avec les résultats des composants peuvent être difficiles à prévoir. Même des corrections de bogues mineures peuvent introduire des changements dans les hypothèses que vous aviez à propos du composant qui peuvent ne plus être vraies. Chaque composant Auth0 de code source ouvert qui suit semver aura une balise correspondant à une version publiée dans son dépôt Git. Comme certains projets utilisent l’outil npm pour publier les versions, la lettre v sera utilisée comme préfixe. Par exemple, la balise de la version 5.2.3 sera v5.2.3.

​
En savoir plus