Comprendre les Versions Logicielles
Les versions logicielles jouent un rôle crucial dans le développement et la maintenance de sites web / logiciels / applications.
9 min
Les versions logicielles permettent de suivre l’évolution d’un programme informatique tout en offrant des améliorations, des corrections de bugs et de nouvelles fonctionnalités.
Dans cet article, nous allons explorer en détails ce qu’est une version logicielle et examiner pourquoi elles sont si importantes. Nous plongerons également dans la notation utilisée pour identifier les différentes versions.
Qu’est-ce qu’une version logicielle ?
Une version logicielle est une itération spécifique d’un programme informatique. Elle est désignée par un numéro de version unique qui indique l’étape de développement du produit.
Il peut s’agir :
- D’un logiciel
- D’un site web
- D’une application mobile
- D’un langage
- D’un framework
- D’une librairie
- Etc.
Une version logicielle prend la forme suivante :
v<version-majeure>.<version-mineure>.<patch> <phase>
Voici une brève explication des différents composants de la notation 👇
Version majeure
Le numéro de version majeur indique des changements majeurs impactant le logiciel tout entier. Il peut s’agir de :
- Refonte globale de l’interface utilisateur
- Modification de l’architecture
- Ajout d’une fonctionnalité principale (révolutionnant le logiciel)
- Etc.
Exemple de changement de version majeure :
v.3.7.2 -> v.4.0
Version mineure
Le numéro de version mineur est utilisé pour signaler des améliorations et de nouvelles fonctionnalités mineures.
Ces changements sont généralement plus modestes que les changements majeurs. ils n’impactent pas le logiciel dans son ensemble mais une partie seulement.
Il peut s’agir de :
- Prise en considération d’un nouveau format d’export (
.png,.svg…) pour une application de type convertisseur. - Ajout d’un moteur de recherche sur un blog
- Ajout de nouvelles icônes et thèmes pour personnaliser l’apparence du logiciel.
- Etc.
Exemple de changement de version mineure :
v.4.0 -> v.4.1
Patch
Le numéro de version de correctif ou de patch indique les correctifs de bugs et les problèmes de performance résolus dans le logiciel.
Ces mises à jour sont essentielles pour garantir un logiciel stable, fiable et sécurisé.
Exemple de changement de version de correctif :
v.4.1.8 -> v.4.1.9
Phase de développement
Les suffixes tels que alpha, nightly, beta, release candidate ou encore stable sont souvent utilisés pour indiquer la phase de développement dans laquelle se trouve une version logicielle.
alpha
La phase alpha (première lettre de l’alphabet grec) est la première étape du développement d’un logiciel.
Dans cette phase, le logiciel est encore en cours de création et contient des fonctionnalités de base. Il est généralement instable et peut contenir des bugs importants. Les versions alpha sont souvent mises à disposition d’un groupe restreint d’utilisateurs, tels que des développeurs internes ou des testeurs, afin de recueillir des commentaires et de détecter les problèmes.
nightly
La phase nightly est souvent utilisée dans les projets de développement logiciel basés sur un modèle de développement continu. Les versions nightly sont créées automatiquement chaque nuit à partir du code source en cours de développement.
Elles sont destinées aux testeurs ou aux développeurs qui souhaitent suivre de près les derniers changements et apports au logiciel. Les versions nightly peuvent être instables et comporter des bugs, car elles représentent les derniers développements du logiciel.
bêta
La phase bêta (deuxième lettre de l’alphabet grec) intervient après la phase alpha.
À ce stade, le logiciel a déjà subi des tests et des corrections de bugs initiaux. Les versions bêta sont généralement mises à la disposition d’un plus grand nombre d’utilisateurs pour obtenir des retours plus étendus et tester le logiciel dans des conditions réelles. Bien qu’il puisse encore comporter quelques bugs, le logiciel est généralement considéré comme plus stable qu’en phase alpha.
release candidate
Lorsque le développement du logiciel atteint la phase release candidate (rc), cela signifie que l’équipe de développement estime que le logiciel est prêt à être lancé officiellement.
Dans cette phase, le logiciel a subi des tests approfondis et les problèmes majeurs ont été résolus. Les versions release candidate sont souvent distribuées à un groupe plus large d’utilisateurs pour effectuer les derniers tests et vérifications avant le lancement officiel.
stable
Une fois que le logiciel a passé avec succès toutes les phases précédentes et que toutes les erreurs et les problèmes ont été résolus, il est considéré comme stable.
Une version stable est celle qui est prête à être utilisée par le grand public. Cela signifie que le logiciel est généralement exempt de bugs majeurs et qu’il est considéré comme fiable et sûr pour une utilisation régulière.
La notation utilisée pour les versions logicielles offre une manière claire et structurée d’identifier les différentes étapes de développement.
- Les versions majeures, mineures et de correctifs définissent les améliorations spécifiques apportées au logiciel
- Les suffixes tels que
alphaoubêtaindiquent la phase de développement dans laquelle se trouve une version.
À quoi servent-elles ?
Les versions logicielles jouent un rôle essentiel dans le développement et la maintenance des logiciels en offrant plusieurs atouts.
1. Amélioration continue
Les versions logicielles permettent aux développeurs d’apporter des améliorations régulières au logiciel en fonction des retours des utilisateurs et des besoins du marché. Cela garantit que le logiciel reste compétitif et répond aux attentes des utilisateurs.
2. Correction des bugs
Les versions de correctif ou de patch permettent de résoudre les problèmes de stabilité, les bugs et les failles de sécurité découverts dans les versions précédentes. Ces mises à jour sont essentielles pour garantir un logiciel fiable et sécurisé.
3. Nouvelles fonctionnalités
Les versions majeures et mineures offrent l’occasion d’introduire de nouvelles fonctionnalités qui améliorent l’expérience utilisateur et permettent aux utilisateurs de tirer parti des dernières innovations technologiques.
4. Compatibilité ascendante
Les versions logicielles sont conçues pour être autant que possible compatibles avec les versions précédentes, de sorte que les utilisateurs puissent mettre à jour leur logiciel sans perdre leurs données ou leur configuration.
Les « breaking changes »
Les versions logicielles peuvent comporter des changements incompatibles, connus sous le nom de « breaking changes », qui peuvent affecter la compatibilité ascendante.
Les breaking changes (ou changements incompatibles) sont des modifications apportées à un logiciel qui entraînent une incompatibilité avec les versions précédentes. Ces changements altèrent le fonctionnement existant du logiciel de manière à ne plus être compatibles avec les utilisations antérieures ou les intégrations existantes.
Les breaking changes peuvent prendre différentes formes, notamment :
- Suppression d’une fonctionnalité : Une fonctionnalité existante est supprimée, ce qui peut nécessiter des ajustements ou des modifications dans le code ou les flux de travail qui l’utilisaient.
- Modification de l’interface : Une modification est apportée à l’interface d’une fonction ou d’un module, entraînant des erreurs de compilation ou d’exécution lors de l’utilisation de l’ancienne interface.
- Changement de comportement : Le comportement d’une fonction ou d’une API est modifié, ce qui peut entraîner des résultats différents ou des erreurs lors de l’utilisation des anciens appels de fonction.
- Changement de format de données : Un changement dans la structure ou le format des données échangées par le logiciel peut entraîner des erreurs lors de la manipulation des données existantes.
Les développeurs doivent fournir des informations claires sur les modifications incompatibles et les éventuelles étapes nécessaires pour migrer les applications ou les données existantes vers la nouvelle version.
La compatibilité ascendante est une préoccupation importante dans le domaine du développement logiciel, et les développeurs s’efforcent généralement de minimiser les breaking changes autant que possible. Cependant, dans certains cas, ces modifications sont nécessaires pour introduire de nouvelles fonctionnalités, améliorer les performances ou résoudre des problèmes techniques.
Il est donc essentiel pour les utilisateurs et les développeurs de prendre en compte la possibilité de breaking changes lors de la mise à jour d’un logiciel et de se familiariser avec les notes de version et les guides de migration fournis par les développeurs pour s’assurer d’une transition en douceur vers la nouvelle version.
Changelog
Un changelog est un document qui répertorie les modifications, les ajouts et les suppressions apportés à un logiciel ou à une application entre différentes versions. Il s’agit essentiellement d’un journal des modifications qui permet aux utilisateurs, aux développeurs et aux autres parties prenantes de suivre l’évolution du logiciel.
Exemple de changelog :
# v.2.1.2 (16/06/2023)
- Correction du bug fonction "remember me" sur le formulaire de connexion.
# v.2.1.1 (02/06/2023)
- Correction du bug pour lequel les typos Google Fonts ne se chargaient pas systématiquement.
- Latence du moteur de recherche corrigée
# v.2.1 (19/04/2023)
- Traduction de l'interface en anglais
- Correction de bugs mineurs
# v.2.0 (01/02/2023)
- La fonction buildBlock() devient générique et se nomme désormais build(type) et précise en argument l'élément à créer.
- Correction de bug : le builder ne se chargait pas sur Safari.
# v.2.0 bêta (05/12/2022)
- Refonte intégrale du page builder
- Options de customisation du thème
...
Pour chacune des version, le changelog peut inclure des informations telles que :
- Les nouvelles fonctionnalités ajoutées
- Les améliorations de performance
- Les correctifs de bugs
- Les modifications de l’interface utilisateur
- Les changements d’API
- Les mises à jour de sécurité
- Les mises à niveau de bibliothèques externes
- Les breaking changelogs
- Etc.
Le but du changelog est de fournir une transparence et une visibilité sur les modifications apportées à un logiciel.
Il permet d’une part aux utilisateurs de savoir ce qui a changé entre les différentes versions, de comprendre les améliorations ou les corrections apportées, et d’évaluer si une mise à jour est nécessaire ou souhaitable.
Pour les développeurs, le changelog est un outil précieux pour communiquer avec la communauté des utilisateurs et les autres développeurs. Il permet de documenter et de partager les détails des changements, de recueillir des commentaires et des rapports de bugs, et de maintenir une traçabilité des évolutions du logiciel.
Les changelogs sont généralement organisés de manière chronologique, avec les modifications les plus récentes en haut de la liste. Ils peuvent être inclus dans la documentation du logiciel, publiés sur des plateformes de développement collaboratives, ou même affichés directement dans l’interface utilisateur de l’application pour informer les utilisateurs des dernières mises à jour.