Construisez un site web à l'aide du framework Symfony 7

Découvrez le versioning de Symfony

Il y a une chose importante dont nous n'avons pas encore parlé. Ce n’est pas nécessaire pour apprendre à coder avec Symfony, mais ça l’est pour apprendre à maintenir vos applications Symfony. Il s’agit du versioning de Symfony.

C’est un sujet lié sur certains points, mais non, il ne s’agit pas de cela. Il s’agit tout simplement de comprendre les numéros de version de Symfony.

À l’heure où ce cours est écrit, Symfony est disponible en version  7.0.3  . Vous avez sans doute déjà rencontré ce type de numéro de version en trois parties. Ce que vous ne saviez peut-être pas, c’est qu’il s’agit d’une norme bien établie pour numéroter n’importe quel application ou logiciel.

Concrètement, cette norme nous oblige à une nomenclature bien précise, et elle a été adaptée pour Symfony à un calendrier bien précis, qui a été fixé depuis la version  3.0  de Symfony. Prenons l’exemple de la version  7.0.3  :

1. Le 7, premier chiffre, est le numéro de version majeure. Dans Symfony, une release (ou publication) majeure a lieu tous les deux ans en novembre, et cause donc l’augmentation de ce chiffre. La prochaine est prévue pour novembre 2025, en version 8.

2. Le 0, chiffre du milieu, est le numéro de version mineure. Une nouvelle release mineure a lieu tous les six mois, une en mai et une en novembre. Les ajouts de fonctionnalités ne peuvent se faire que dans ces versions.

3. Le 3, chiffre de droite, est le numéro de version patch. Une nouvelle release patch a lieu environ tous les mois pour Symfony.

À chaque fois qu’un numéro de version mineure augmente, le numéro de version patch est remis à zéro. De même, lorsque le numéro de version majeure augmente, le numéro de version mineure ET le numéro de version patch sont remis à zéro. Ainsi, la nouvelle version majeure sortie en novembre 2023 était la version  7.0.0  .

Les numéros de versions mineures s’arrêtent à 4 dans Symfony. Chaque version mineure est maintenue pendant huit mois. Cela signifie que pendant ces huit mois, la version mineure bénéficiera de releases patch mensuelles pour corriger les bugs ou failles de sécurité qui seraient trouvés.

La version mineure 4, elle, est spéciale. Les bugs qui sont trouvés dans Symfony sont corrigés dessus pendant 3 ans, et les failles de sécurité pendant une année supplémentaire. On appelle donc ces versions des versions LTS, pour Long Term Support. Ces versions sont idéales à utiliser sur les projets dont la phase de développement sera assez courte, mais sur lesquels vous devrez faire de la maintenance par la suite. 

Une version patch par mois pendant huit mois veut donc dire que sur les versions mineures 0, 1, 2, et 3, le numéro de patch maximal se situe généralement en dessous de 10 (on aura donc des versions  x.1.7  , mais pas  x.1.22  , par exemple). Sur les versions LTS par contre, le numéro de version patch peut augmenter beaucoup plus. Par exemple, le numéro de version de la LTS de Symfony 5 est actuellement  5.4.35  .

Comprenez la rétrocompatibilité

Des améliorations ! Mais ces améliorations ne sont pas forcément des ajouts de fonctionnalités. Parfois, une amélioration peut impliquer le changement de fonctionnement d’un composant, ou le remplacement d’une classe au profit d’une autre, voire sa suppression pure et simple.

C’est pour cela que Symfony a développé sa Backward Compatibility Promise, (BC Promise) ou "promesse de rétrocompatibilité".

Cette promesse découle directement de la SemVer. La SemVer stipule en effet que les releases de versions mineures doivent forcément être rétrocompatibles, et que seuls les changements non rétrocompatibles seront limités aux releases de versions majeures. Mieux, dans Symfony, les développeurs s’assurent que vous en serez toujours prévenus à l’avance par un système de dépréciations.

Concrètement, lorsque des contributeurs de Symfony voudront supprimer une classe, la remplacer ou modifier drastiquement son fonctionnement, une dépréciation sera ajoutée dessus. Cela signifie qu'à chaque fois que vous utiliserez cette classe, une alerte apparaîtra dans votre Profiler, ainsi qu’à d’autres endroits clés, vous avertissant que cette classe sera bientôt supprimée et vous proposant un remplacement.

Ces dépréciations sont ajoutées lors de releases mineures, afin de vous laisser le temps de refactoriser (ou réécrire) le code concerné. Puis, lors de la release majeure suivante, tout le code qui avait été déprécié lors des versions mineures précédentes est supprimé.

C’est d'ailleurs la seule chose qui est faite lors d’une release majeure, avec l’augmentation de la version minimale de PHP demandée par Symfony. En clair, le processus complet ressemble donc à ça :

1. Une nouvelle version majeure sort en version  x.0.0  .

2. Des bugs sont corrigés, des versions patch sortent au moins une fois par mois.

3. Des développeurs proposent des ajouts de fonctionnalités, des changements de fonctionnement, et ajoutent des dépréciations lorsque le changement est non rétrocompatible.

4. Six mois après la sortie de la dernière version majeure, la première version mineure est publiée en embarquant ces ajouts, changements et dépréciations (x.1.0).

5. On répète les étapes 2 à 4 fois, jusqu’à arriver à la version LTS  x.4.0  .

6. La nouvelle version majeure est alors publiée. Elle embarque exactement le même code que la version LTS qui sort en même temps, moins le code qui était déprécié.

Comprendre le calendrier des sorties de Symfony

Ce fonctionnement est généralement bien résumé par le calendrier suivant, disponible sur le site de Symfony : 

Cela vous permet aussi de voir clairement comment vous pouvez mettre à jour vos applications Symfony :

• Lorsque vous voulez faire une mise à jour entre deux versions patch (passer de la  x.0.2  à la  x.0.6  , par exemple) ou entre deux versions mineures (de la  x.1.y  à la  x.3.z  , par exemple) , il y a très peu de risque que cela casse votre application.

• Dans le cas d’une mise à jour d’une version mineure à une autre, vous verrez par contre sans doute de nouvelles dépréciations apparaître dans votre Profiler.

• Si par contre vous voulez faire une mise à jour d’une version majeure à une autre (de la  6.x.y  à la  7.z.a  par exemple), la solution la plus sûre est souvent de commencer par mettre à jour jusqu’à la version LTS la plus proche (dans notre exemple, la  6.4  ), inspecter et corriger votre code pour vous débarrasser de toutes les dépréciations, et ensuite passer à la version majeure suivante.

Découvrez les communautés Open Source

Il nous reste un dernier sujet à traiter dans ce cours, et pas des moindres : comment Symfony continue à vivre.

Symfony est un projet libre et open source publié sous licence MIT. Concrètement, la licence dite “MIT” signifie que n’importe qui obtenant le code source de Symfony a le droit de le copier, le distribuer, le modifier, et même de le vendre ou de l’inclure dans une application commerciale sans aucune restriction. La seule obligation est d’inclure la licence d’origine dans le code qui utilise Symfony. Comme open source signifie que n’importe qui peut obtenir le code de Symfony, les possibilités sont infinies.

Cependant, une autre caractéristique de Symfony est ici importante : Symfony est maintenu et amélioré par une communauté publique. Il n’y a pas d’entreprise qui détienne Symfony et qui se charge de sa maintenance et de son amélioration continue.

Cela signifie donc que c’est sur la bonne volonté des développeurs utilisateurs de Symfony, sa communauté, que repose la charge de veiller à la survie et à l’évolution de Symfony. Et si vous avez terminé ce cours, vous en faites désormais partie !

Faites partie de la communauté

Très concrètement, vous êtes tout à fait encouragé à vous rendre sur le dépôt GitHub de Symfony et à proposer des changements de code, que ce soient des corrections de bug, de nouvelles fonctionnalités, des optimisations ou de la documentation (qui se trouve sur un dépôt GitHub séparé).

Je vais vous faire une confidence, c’est ce que je pensais aussi au début de ma carrière. Mais en fait, il y a très peu de risques que ce soit le cas, pour ne pas dire aucun.

Pourquoi ?

Déjà, grâce aux guides de contribution fournis par Symfony. Toute la procédure pour proposer du code, et surtout tester qu’il ne casse rien, est parfaitement documentée sur un ensemble de pages dédiées. Si vous suivez ces étapes et que vous testez votre code, vous réduisez déjà grandement les risques.

Ensuite, l’organisation de la communauté vous sécurise. Car si tout le monde peut proposer un changement de code par le biais d’une Pull Request, seul un petit nombre de développeurs de confiance appelé la Core Team a le pouvoir de valider ces changements. Ainsi, vous ouvrez votre Pull Request, de nombreuses personnes font une revue de code, vous posent des questions, vous proposent des améliorations, et seulement une fois que tout est bon, un membre de la Core Team valide la Pull Request.

De plus, si vous avez des doutes sur un changement à proposer, ou simplement que vous souhaitez participer à cette aventure sans savoir par où commencer, un outil supplémentaire peut vous aider. Rendez-vous sur le panneau dédié aux tickets (ou “Issues”) de Symfony, et filtrez ceux qui portent le label “Good First Issue”. Ce sont généralement des issues simples, qui forment un bon point de départ pour votre première contribution ! 

Enfin, n'hésitez pas à vous rendre dans les conférences autour du framework Symfony, comme le Symfony Live qui a lieu tous les ans à Paris. Vous y trouverez toujours des développeurs et développeuses plus expérimentés prêts à vous accompagner dans votre première contribution.

Alors n'hésitez plus et lancez-vous, Symfony a toujours besoin de nouvelles contributions !

En résumé

• Symfony est un framework libre et open source qui n’appartient à aucune entreprise.

• Symfony suit la norme SemVer pour ses numéros de versions.

• Un calendrier de release très précis a été mis en place grâce à cette norme.

• La Backward Compatibility Promise de Symfony assure que les changements apportés à Symfony seront toujours rétrocompatibles au sein d’une même version majeure.

• Les dépréciations vous aident à identifier à l’avance les changements non rétrocompatibles.

• N’importe qui peut proposer un changement de code ou de documentation, mais seule la Core Team peut valider ces changements.

Vous êtes arrivé au bout de ce cours, et ce n'était pas une mince affaire. Félicitations !