Historique de Spring Boot et versions réelles des dépendances
Sur cette page
Spring Boot et Spring Framework sont des projets distincts aux numéros de version différents. Boot ajoute la configuration automatique, la gestion des dépendances et l’empaquetage exécutable autour de Framework. Interpréter Boot 3.1 comme Framework 6.1 n’est donc pas fiable ; inspectez plutôt la BOM de la release Boot choisie et le graphe résolu des dépendances.
Déroulement du traitement
Le flux résume l’inspection des dépendances, et non une chronologie des releases. Boot, Framework et Lombok possèdent des identités de version et des configurations de dépendances distinctes.
Changements de certaines versions finales
Cette chronologie souligne des évolutions fonctionnelles au lieu d’énumérer toutes les releases. Distinguez la première version finale de l’élargissement de compatibilité JDK dans les correctifs ultérieurs.
| Spring Boot | Première version finale | Changements retenus et annonce officielle |
|---|---|---|
| 1.2 | 2014-12-11 | @SpringBootApplication et prise en charge de Servlet 3.1 |
| 1.3 | 2015-11-16 | DevTools, configuration automatique du cache et JAR directement exécutables |
| 1.4 | 2016-07-28 | Analyse des échecs de démarrage et amélioration des tests |
| 2.0 | 2018-03-01 | Framework 5.0, base Java 8 et prise en charge du Web réactif |
| 3.0 | 2022-11-24 | Framework 6.0, base Java 17, Jakarta et images natives |
| 3.1 | 2023-05-18 | Testcontainers pendant le développement et intégration Docker Compose |
| 3.2 | 2023-11-23 | Prise en charge des threads virtuels, de RestClient et de JdbcClient |
| 4.0 | 2025-11-20 | Framework 7, modularisation, JSpecify et gestion des versions d’API |
Par exemple, la liste des dépendances gérées de Boot 3.1.0 indique spring-core 6.0.9. Les numéros mineurs de Boot et Framework n’ont pas à correspondre. Associer Boot 2.4 à une branche Framework 5.4 inexistante est également incorrect.
Starters, BOM et plugins de construction
Un starter regroupe les dépendances nécessaires à une fonctionnalité. Une BOM gère les versions ; elle n’ajoute pas automatiquement toutes les bibliothèques de sa liste au projet. Le plugin de construction Boot fournit des tâches telles que bootRun et l’empaquetage de JAR exécutables.
Pour Gradle, le guide Boot de gestion des dépendances décrit le plugin de gestion des dépendances et la prise en charge native des BOM. Appliquer uniquement le plugin Boot ne garantit pas que toutes les configurations Gradle acceptent des dépendances sans version. Vérifiez aussi les configurations distinctes telles que les processeurs d’annotations.
Inspecter les versions réelles du projet
Exécutez ces commandes dans le projet final des guides Initializr et Lombok.
./gradlew dependencyInsight --configuration runtimeClasspath --dependency spring-core
./gradlew dependencyInsight --configuration annotationProcessor --dependency lombokL’exemple local résout Boot 4.1.2, spring-core 7.0.10 et Lombok 1.18.48. Les numéros différents reflètent des projets différents. dependencyInsight montre la version sélectionnée et les chemins de dépendances ou règles responsables, ce qui aide à rechercher les conflits. Ces valeurs décrivent cet exemple, et non de futures valeurs par défaut ou une combinaison universelle de projet.
La chronologie n’est pas une table actuelle des cycles de support. Lors de la création ou de la mise à niveau d’un projet, vérifiez séparément les exigences, la compatibilité des dépendances et la politique de support de la release choisie. Voir la migration Java 17 et Jakarta pour passer à Boot 3, ou les contrôles d’exécution IntelliJ et Gradle pour l’exécution locale.
Discussion