Schéma de dénomination des versions de Spring Projects

1. Vue d'ensemble

Il est courant d'utiliser la gestion des versions sémantiques lors de la dénomination des versions. Par exemple, ces règles s'appliquent pour un format de version tel que MAJOR.MINOR.REVISION :

  • MAJEUR: fonctionnalités majeures et changements de rupture potentiels
  • MINEUR: fonctionnalités rétrocompatibles
  • RÉVISION : corrections et améliorations rétrocompatibles

Avec la gestion des versions sémantiques, les projets utilisent souvent des étiquettes pour clarifier davantage l'état d'une version particulière. En fait, en utilisant ces étiquettes, nous donnons des conseils sur le cycle de vie de la construction ou sur l'endroit où les artefacts sont publiés.

Dans cet article rapide, nous examinerons les schémas de dénomination de version adoptés par les principaux projets Spring.

2. Spring Framework et Spring Boot

En plus de la gestion des versions sémantiques, nous pouvons voir que Spring Framework et Spring Boot utilisent ces étiquettes:

  • BUILD-INSTANTANÉ
  • M [ nombre ]
  • RC [ numéro ]
  • LIBÉRATION

BUILD-SNAPSHOT est la version de développement actuelle. L'équipe Spring crée cet artefact chaque jour et le déploie sur //maven.springframework.org/snapshot.

Une version Milestone (M1, M2, M3,…) marque une étape importante dans le processus de publication. L'équipe crée cet artefact lorsqu'une itération de développement est terminée et le déploie sur //maven.springframework.org/milestone.

Une version Release Candidate (RC1, RC2, RC3,…) est la dernière étape avant la création de la version finale. Pour minimiser les changements de code, seules des corrections de bogues devraient se produire à ce stade. Il est également déployé sur //maven.springframework.org/milestone.

À la toute fin du processus de publication, l'équipe Spring produit un RELEASE. Par conséquent, il s'agit généralement du seul artefact prêt pour la production. Nous pouvons également désigner cette version comme GA, pour la disponibilité générale .

Ces étiquettes sont classées par ordre alphabétique pour s'assurer que les gestionnaires de build et de dépendance déterminent correctement si une version est plus récente qu'une autre. Par exemple, Maven 2 a considéré à tort 1.0-SNAPSHOT comme plus récent que 1.0-RELEASE. Maven 3 a corrigé ce problème. En conséquence, nous pouvons expérimenter des comportements étranges lorsque notre schéma de dénomination n'est pas optimal.

3. Projets parapluie

Les projets parapluies, comme Spring Cloud et Spring Data, sont des projets sur des sous-projets indépendants mais liés. Pour éviter les conflits avec ces sous-projets, un projet parapluie adopte un schéma de dénomination différent. Au lieu d'une version numérotée, chaque Release Train a un nom spécial.

Dans l'ordre alphabétique, les stations de métro de Londres sont l'inspiration des noms de sortie de Spring Cloud - pour les débutants, Angel, Brixton, Finchley, Greenwich et Hoxton.

En plus des libellés Spring illustrés ci-dessus, il définit également un libellé Service Release (SR1, SR2…) . Si nous trouvons un bogue critique, une version de service peut être produite.

Il est important de réaliser qu'une version de Spring Cloud n'est compatible qu'avec une version spécifique de Spring Boot. À titre de référence, la page Spring Cloud Project contient le tableau de compatibilité.

4. Conclusion

Comme indiqué ci-dessus, il est important d'avoir un schéma de dénomination de version clair. Bien que certaines versions telles que Milestones ou Release Candidates puissent être stables, nous devons toujours utiliser des artefacts prêts pour la production. Quel est votre schéma de dénomination? Quels avantages a-t-il par rapport à celui-ci?