Le versionnage des Logiciels

Versions majeure, mineure, alpha, bêta… quelles différences ? Petit guide pour mieux comprendre le versionnage (ou versioning) des logiciels.

Connaître la version d'un logiciel

Avant d'aller plus loin, il peut être utile de savoir comment connaître la version d'un logiciel. C'est une information qui est primordiale lors de l'analyse ou la reproduction de bugs.

Pour les logiciels embarquant une interface graphique, on peut généralement trouver cette information dans le menu Aide ou À Propos.

Pour les sites web, il faut se rendre sur la page Aide ou À Propos. Ainsi dans VSA, il suffit de cliquer sur sa photo en haut à droite de la page d'accueil et cliquer sur le lien A propos de l'application pour afficher la fenêtre modale suivante :

Pour les logiciels utilisables en ligne de commande il existe souvent une commande comme <mon_logiciel> --version pour afficher la version installée. Exemples: pour connaître les versions de Python, Java et PowerShell installées sur un serveur, utilisez les commandes suivantes :

Ce qui correspond à Python 2.7 ; Java 8 et PowerShell 5.1.

Quelle version choisir ?

Il est généralement conseillé d'utiliser la dernière version stable d'un logiciel, compatible avec votre environnement (système d'exploitation, architecture matérielle). Attention également aux problèmes de licences ! N'hésitez pas à consulter votre client.

Faites régulièrement des mises à jour pour profiter des corrections de bugs, des nouvelles fonctionnalités et des derniers correctifs de sécurité.

Numérotation

Chaque éditeur/projet est libre d'utiliser sa propre numérotation.

Semantic Versioning

La numérotation de type X.Y.Z est utilisée par de nombreux logiciels.

La convention Semantic Versioning propose la signification suivante :

  • X correspond à la version majeure : changements non rétrocompatibles. Les évolutions majeures apportent de nouvelles fonctionnalités, en changeant radicalement l'apparence ou l'architecture du logiciel.
  • Y correspond à la version mineure : ajouts de fonctionnalités rétrocompatibles, principalement des corrections de bugs, ajouts de quelques fonctionnalités.
  • Z correspond au correctif : corrections d’anomalies rétrocompatibles, failles de sécurité

Cette convention est de plus en plus adoptée, notamment dans le milieu de l'open-source, comme Python.

Version horodatée

D'autres logiciels s’appuient sur la date/année de publication comme mode de numérotation. C'est particulièrement vrai pour les logiciels grand public ainsi que les logiciels publiés à un rythme bien défini.

Les logiciels Microsoft ont longtemps utilisé cette convention comme Windows 95 (vendu en 1995) ou Microsoft Office 2013 (vendu en 2013). Ces versions correspondent à des versions "grand public" facile à retenir.

Le logiciel Ubuntu (une des nombreuses distributions Linux existantes) propose une nouvelle version tous les 6 mois : aux mois d'avril et aux mois d'octobre. On peut ainsi télécharger les versions de l'année dernière, numérotés Ubuntu 18.04 et Ubuntu 18.10.

Version commerciale et version interne

Certains logiciels possèdent en faite 2 numéro de versions :

  • Une version commerciale ou "grand public"
  • Une version interne

Il est en effet plus facile de retenir le nom commercial d'un logiciel que celui de sa version interne.

C'est le cas par exemple du système d'exploitation Microsoft Windows :

Autre exemple, les bases de données Oracle :

On peut remarquer que :

  • La version "v1" n'a jamais existé : le fondateur d'Oracle, Larry Ellison, a préféré nommer la première version de son produit en "v2" pour rassurer ses clients.
  • Oracle utilise des suffixes "marketing" dans le nom de ses produits selon la tendance du moment : i pour Internet, g pour grid, c pour cloud.
  • Oracle est passé d'un coup de la v12 à la v18 pour aligner le numéro de version avec l'année de mise en production.

Version en cours de test

Les logiciels en cours de tests/développements utilisent souvent un numéro de version avec un suffixe comme alpha, beta, RC (Release Candidate) en fonction du cycle de développement du logiciel.

Ces logiciels, en cours de développement, sont principalement utilisés par les beta-users ou les early adopters pour remonter des bugs assez tôt. Exemple de logiciel: PHP

D'autres logiciels adoptent une numérotation qui finit avec un nombre pair pour les logiciels stables, et un nombre impair pour les versions instables.

Dans le monde de l'open-source on peut trouver des logiciels en version 0.x. Il est souvent admis qu'un logiciel qui n'a pas encore atteint la v1 n'est pas encore stable.

Long-Term Support

Certains logiciels sont en version LTS (Long-Term Support). Ces versions LTS ont une durée de maintenance supérieure par rapport aux versions standards.

Ces versions LTS sont souvent privilégiées par les entreprises car elles leur garantissent la disponibilité de correctifs sur plusieurs années sans prendre le risque de faire une "montée de version".

Ainsi Ubuntu 18.04 LTS a une maintenance de 5 ans, alors qu'Ubuntu 18.10 a une période de maintenance de 2 ans.

Autres exemples :

Édition entreprise/communautaire

Certains logiciels sont offerts en 2 modes différents :

  • Mode CE ou Community Edition : version open-source du logiciel, gratuit
  • Mode EE ou Enterprise Edition : version payante du même logiciel, avec des fonctionnalités supplémentaires, à l'intention des entreprises.

Exemple : Docker 18.09 CE

Anecdotes

Les versions de logiciels ne sont pas à l'abri de quelques bizarreries :

  • Le langage PHP est passé directement de la version 5 à la version 7. En effet, PHP 6 n'a jamais vu le jour, victime de sa mauvaise réputation lors de son développement. Les développeurs ont préféré repartir d'une feuille blanche et de passer directement à PHP 7.
  • Le noyau Linux change de version majeure de manière complétement arbitraire selon l'humeur de Linus Torvalds, son créateur.
  • Certains éditeurs, comme Microsoft, évitent de proposer une version 13 par superstition autour de ce nombre.

Sécurité

Les logiciels ne sont pas épargnés par les bugs et les failles de sécurité. Des sites institutionnels comme le (Centre gouvernemental de veille, d'alerte et de réponse aux attaques informatiques (CERT-FR) OU CVE Details répertorient les différentes vulnérabilités de chaque version de logiciel.

Exemple: Vulnérabilités connues dans Wordpress 4.9.8

Conseil pour les développeurs

  • Si vous créez un logiciel, utilisez une convention comme le Semantic Versioning.
  • Maintenez une liste des changements (CHANGELOG ou Release Notes) pour chaque version et fournissez-la à l'équipe de production avec le déploiement.
  • Gérez les dépendances de vos logiciels avec un outil dédié (Apache Maven, Python pip, NuGet, npm).
  • Analysez régulièrement vos projets pour détecter des libraires tierces obsolètes ou vulnérables.

Conseil pour les ingénieurs de production

  • Vérifiez que la version testée dans un environnement de test est identique à celle que vous vous apprêtez à déployer en production.
  • Il est fortement déconseillé d'installer un logiciel non finalisé (en version alpha ou beta) en production.
  • Lisez la liste des changements (CHANGELOG ou Release Notes) avant le déploiement d'une nouvelle version.

Allez plus loin


Antoine, 7 février 2019