Gestion des versions du logiciel - Software versioning
Le contrôle de version de logiciel est le processus d'attribution de noms de version uniques ou de numéros de version uniques à des états uniques de logiciels informatiques. Au sein d'une même catégorie de numéros de version (majeure, mineure), ces numéros sont généralement attribués par ordre croissant et correspondent aux évolutions du logiciel. À un niveau plus fin, le contrôle de révision est souvent utilisé pour garder une trace de différentes versions d'informations, que ces informations soient ou non des logiciels informatiques.
Les logiciels informatiques modernes sont souvent suivis à l'aide de deux schémas de version de logiciel différents : un numéro de version interne qui peut être incrémenté plusieurs fois en une seule journée, tel qu'un numéro de contrôle de révision, et une version de version qui change généralement beaucoup moins souvent, telle que le contrôle de version sémantique ou un nom de code de projet .
Schémas
Divers schémas de numérotation des versions ont été créés pour suivre les différentes versions d'un logiciel. L'omniprésence des ordinateurs a également conduit à l'utilisation de ces schémas dans des contextes extérieurs à l'informatique.
Identifiants basés sur la séquence
Dans les schémas de gestion de versions de logiciels basés sur des séquences, chaque version de logiciel se voit attribuer un identifiant unique composé d'une ou plusieurs séquences de chiffres ou de lettres. C'est l'étendue de la communauté; les schémas varient considérablement dans des domaines tels que la quantité de séquences, l'attribution de sens aux séquences individuelles et les moyens d'incrémenter les séquences.
- Changer la signification
Dans certains schémas, des identificateurs basés sur des séquences sont utilisés pour indiquer l'importance des changements entre les versions. Les modifications sont classées par niveau de signification, et la décision de la séquence à modifier entre les versions est basée sur la signification des modifications par rapport à la version précédente, la première séquence étant modifiée pour les modifications les plus importantes, et les modifications apportées aux séquences après la première représentent changements d'importance décroissante.
Selon le schéma, l'importance peut être évaluée par des lignes de code modifiées, des points de fonction ajoutés ou supprimés, l'impact potentiel sur les clients en termes de travail requis pour adopter une nouvelle version, le risque de bogues ou de changements de rupture non déclarés, le degré de changements dans la disposition visuelle , la quantité de nouvelles fonctionnalités ou presque tout ce que les développeurs de produits ou les spécialistes du marketing jugent important, y compris le désir de marketing de souligner la « bonté relative » de la nouvelle version.
Le contrôle de version sémantique (aka SemVer) est un schéma de version largement adopté qui utilise une séquence de trois chiffres (Major.Minor.Patch), une balise de pré-version facultative et une balise méta de construction facultative. Dans ce schéma, le risque et la fonctionnalité sont les mesures de l'importance. Les changements majeurs sont indiqués par l'augmentation du nombre majeur (risque élevé), les nouvelles fonctionnalités incassables incrémentent le nombre mineur (risque moyen) et tous les autres changements non majeurs incrémentent le numéro de patch (risque le plus faible). La présence d'une balise de pré-version (-alpha, -beta) indique un risque substantiel, tout comme un nombre majeur de zéro (0,yz), qui est utilisé pour indiquer un travail en cours qui peut contenir n'importe quel niveau de potentiel changements de rupture (risque le plus élevé).
Les développeurs peuvent choisir de sauter plusieurs versions mineures à la fois pour indiquer que des fonctionnalités importantes ont été ajoutées, mais ne suffisent pas pour justifier l'incrémentation d'un numéro de version majeure ; par exemple Internet Explorer 5 de 5.1 à 5.5, ou Adobe Photoshop 5 à 5.5. Cela peut être fait pour souligner la valeur de la mise à niveau pour l'utilisateur du logiciel, ou, comme dans le cas d'Adobe, pour représenter une version à mi-chemin entre les versions principales (bien que les niveaux de versionnage basés sur la séquence ne soient pas nécessairement limités à un seul chiffre, comme dans Blender version 2.91 ou Minecraft Java Edition après 1.10).
Une approche différente consiste à utiliser les numéros majeurs et mineurs , ainsi qu'une chaîne alphanumérique indiquant le type de version, par exemple "alpha" (a), "beta" (b) ou "release candidate" (rc). Un train de versions logicielles utilisant cette approche pourrait ressembler à 0.5, 0.6, 0.7, 0.8, 0.9 → 1.0b1, 1.0b2 (avec quelques correctifs), 1.0b3 (avec plus de correctifs) → 1.0rc1 (qui, s'il est suffisamment stable ) , 1.0rc2 (si plus de bogues sont trouvés) → 1.0. C'est une pratique courante dans ce schéma de verrouiller les nouvelles fonctionnalités et les changements de rupture au cours des phases de publication candidate et pour certaines équipes, même les versions bêta sont verrouillées uniquement pour les corrections de bogues, afin d'assurer la convergence sur la version cible.
D'autres schémas donnent un sens à des séquences individuelles :
- major.minor[.build[.revision]] (exemple : 1.2.12.102 )
- majeur.mineur[.maintenance[.build]] (exemple : 1.4.3.5249 )
Encore une fois, dans ces exemples, la définition de ce qui constitue un changement « majeur » par opposition à un changement « mineur » est entièrement subjective et appartient à l'auteur, tout comme ce qui définit une « construction » ou en quoi une « révision » diffère d'un "changement mineur.
Les bibliothèques partagées sous Solaris et Linux peuvent utiliser le format current.revision.age où :
- current : Le numéro d'interface le plus récent que la bibliothèque implémente.
- révision : Le numéro d'implémentation de l'interface actuelle.
- age : La différence entre les interfaces les plus récentes et les plus anciennes que la bibliothèque implémente. Cette utilisation du troisième champ est spécifique à libtool : d'autres peuvent utiliser un sens différent ou simplement l'ignorer.
Un problème similaire d'importance relative des changements et de nomenclature de version existe dans l'édition de livres, où les numéros d'édition ou les noms peuvent être choisis en fonction de critères variables.
Dans la plupart des logiciels propriétaires, la première version publiée d'un produit logiciel a la version 1.
- Degré de compatibilité
Certains projets utilisent le numéro de version principale pour indiquer les versions incompatibles. Deux exemples sont Apache Portable Runtime (APR) et le CMS FarCry.
Le contrôle de version sémantique est une convention formelle pour spécifier la compatibilité à l'aide d'un numéro de version en trois parties : version majeure ; version mineure; et patch. Le numéro de correctif est incrémenté pour les modifications mineures et les corrections de bogues qui ne modifient pas l' interface de programmation d'application (API) du logiciel . La version mineure est incrémentée pour les versions qui ajoutent de nouvelles fonctionnalités d'API, mais rétrocompatibles, et la version principale est incrémentée pour les modifications d'API qui ne sont pas rétrocompatibles. Par exemple, un logiciel qui s'appuie sur la version 2.1.5 d'une API est compatible avec la version 2.2.3, mais pas nécessairement avec la 3.2.4.
Souvent, les programmeurs écrivent de nouveaux logiciels pour qu'ils soient rétrocompatibles , c'est-à-dire que le nouveau logiciel est conçu pour interagir correctement avec les anciennes versions du logiciel (en utilisant les anciens protocoles et formats de fichiers) et la version la plus récente (en utilisant les derniers protocoles et formats de fichiers). Par exemple, IBM z/OS est conçu pour fonctionner correctement avec 3 versions majeures consécutives du système d'exploitation s'exécutant dans le même sysplex. Cela permet aux personnes qui exécutent un cluster d'ordinateurs à haute disponibilité de maintenir la plupart des ordinateurs opérationnels pendant qu'une machine à la fois est arrêtée, mise à niveau et remise en service.
Souvent, les en-têtes de paquets et le format de fichier incluent un numéro de version – parfois le même que le numéro de version du logiciel qui l'a écrit ; d'autres fois un « numéro de version du protocole » indépendant du numéro de version du logiciel. Le code pour gérer les anciens protocoles et formats de fichiers obsolètes est souvent considéré comme grossier .
- Désignation du stade de développement
Les logiciels au stade expérimental ( alpha ou bêta ) utilisent souvent un zéro dans la première position ("majeure") de la séquence pour désigner son statut. Cependant, ce schéma n'est utile que pour les premiers stades, pas pour les prochaines versions avec un logiciel établi où le numéro de version a déjà dépassé 0.
Un certain nombre de schémas sont utilisés pour indiquer le statut d'une version plus récente :
- Le suffixe alphanumérique est un schéma courant adopté par le contrôle de version sémantique. Dans ce schéma, les versions sont apposées un tiret plus quelques caractères alphanumériques pour indiquer l'état.
- L'état numérique est un schéma qui utilise des nombres pour indiquer l'état comme s'il faisait partie de la séquence. Un choix typique est la troisième position pour le contrôle de version à quatre positions.
- Numeric 90+ est un autre schéma qui utilise des nombres, mais apparemment sous un certain nombre d'une version précédente. Un grand nombre en dernière position, généralement 90 ou plus, est utilisé. Ceci est couramment utilisé par les anciens projets open source comme Fontconfig .
| Organiser | Semver | Num. Statut | 90+ |
|---|---|---|---|
| Alpha | 1.2.0-a.1 | 1.2.0.1 | 1.1.90 |
| Bêta | 1.2.0-b.2 | 1.2.1.2 | 1.1.93 |
| Candidat à la libération | 1.2.0-rc.3 | 1.2.2.3 | 1.1.97 |
| Sortie | 1.2.0 | 1.2.3.0 | 1.2.0 |
| Corrections post-version | 1.2.5 | 1.2.3.5 | 1.2.5 |
Les deux formes purement numériques suppriment la logique spéciale requise pour gérer la comparaison de « alpha < bêta < rc < pas de préfixe » que l'on trouve dans le contrôle de version sémantique, au détriment de la clarté. (le versioning sémantique ne spécifie en fait pas de termes spécifiques pour les étapes de développement ; la comparaison est simplement dans l' ordre lexicographique .)
- Incrémentation des séquences
Il existe deux écoles de pensée concernant la façon dont les numéros de version numériques sont incrémentés. La plupart des logiciels libres et open source , y compris MediaWiki , traitent les versions comme une série de nombres individuels, séparés par des points, avec une progression telle que 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2, etc.
D'autre part, certains progiciels identifient les versions par des nombres décimaux : 1.7, 1.8, 1.81, 1.82, 1.9, etc. Les versions décimales étaient courantes dans les années 1980, par exemple avec NetWare , DOS et Microsoft Windows , mais même dans les années 2000 ont été par exemple utilisés par Opera et Movable Type . Dans le schéma décimal, la 1.81 est la version mineure suivant la 1.8, tandis que les versions de maintenance (c'est-à-dire les corrections de bogues uniquement) peuvent être désignées par un suffixe alphabétique, comme 1.81a ou 1.81b.
Le schéma de numérotation de version GNU standard est major.minor.revision, mais Emacs est un exemple notable utilisant un autre schéma où le numéro majeur (1) a été supprimé et une révision du site utilisateur a été ajoutée qui est toujours zéro dans les packages Emacs d'origine mais augmentée par les distributeurs . De même, les numéros de paquet Debian sont préfixés par une "époque" facultative, qui est utilisée pour permettre la modification du schéma de version.
- Réinitialisation
Dans certains cas, les développeurs peuvent décider de réinitialiser le numéro de version principal. Ceci est parfois utilisé pour désigner une nouvelle phase de développement en cours de publication. Par exemple, Minecraft Alpha a fonctionné de la version 1.0.0 à 1.2.6, et lors de la sortie de la version bêta, il a réinitialisé le numéro de version principal et est passé de 1.0 à 1.8. Une fois le jeu complètement sorti, le numéro de version principale a de nouveau été réinitialisé à 1.0.0.
- Séparation des séquences
A l'impression, les séquences peuvent être séparées par des caractères. Le choix des caractères et leur utilisation varient selon le schéma. La liste suivante montre des exemples hypothétiques de plans de séparation pour la même version (de la treizième révision de troisième niveau à la quatrième révision de deuxième niveau à la deuxième révision de premier niveau) :
- Un schéma peut utiliser le même caractère entre toutes les séquences : 2.4.13, 2/4/13, 2-4-13
- Un choix de schéma des séquences à séparer peut être incohérent, séparant certaines séquences mais pas d'autres : 2.413
- Le choix des caractères d'un schéma peut être incohérent au sein d'un même identifiant : 2.4_13
Lorsqu'un point est utilisé pour séparer des séquences, il peut ou non représenter un point décimal, — voir la section « Incrémentation de séquences » pour divers styles d'interprétation.
- Nombre de séquences
Il existe parfois un quatrième numéro non publié qui désigne la version du logiciel (telle qu'utilisée par Microsoft ). Adobe Flash est un cas notable où un numéro de version en quatre parties est indiqué publiquement, comme dans 10.1.53.64. Certaines entreprises incluent également la date de construction. Les numéros de version peuvent également inclure des lettres et d'autres caractères, tels que Lotus 1-2-3 version 1a.
- Utiliser un nombre négatif
Certains projets utilisent des numéros de version négatifs. Un exemple est le compilateur SmartEiffel qui a commencé à partir de -1,0 et a compté jusqu'à 0,0.
Date de sortie
De nombreux projets utilisent un schéma de version basé sur la date appelé Calendar Versioning (aka CalVer ).
Ubuntu Linux est un exemple de projet utilisant la gestion des versions de calendrier ; Ubuntu 18.04, par exemple, est sorti en avril 2018. Cela a l'avantage d'être facilement lié aux calendriers de développement et aux délais de support. Certains jeux vidéo utilisent également la date comme versionnage, par exemple le jeu d'arcade Street Fighter EX . Au démarrage, il affiche le numéro de version sous forme de date plus un code de région, par exemple 961219 ASIA .
Lors de l'utilisation de dates dans la gestion des versions, par exemple, les noms de fichiers, il est courant d'utiliser le schéma ISO 8601 : AAAA-MM-JJ, car il s'agit facilement de chaînes triées par ordre croissant ou décroissant. Les tirets sont parfois omis. Le projet Wine utilisait auparavant un schéma de version de date, qui utilisait l'année suivie du mois suivi du jour de la publication ; par exemple, "Vin 20040505".
Les numéros de version de Microsoft Office sont une date codée : les deux premiers chiffres indiquent le nombre de mois qui se sont écoulés depuis le mois de janvier de l'année au cours de laquelle le projet a commencé (chaque version principale d'Office étant un projet différent), tandis que les deux derniers chiffres indiquent le jour de ce mois. Donc 3419 est le 19ème jour du 34ème mois après le mois de janvier de l'année où le projet a commencé.
D'autres exemples qui identifient les versions par année incluent Adobe Illustrator 88 et WordPerfect Office 2003. Lorsqu'une année est utilisée pour désigner la version, c'est généralement à des fins de marketing, et un numéro de version réel existe également. Par exemple, Microsoft Windows 95 est versionné en interne en tant que MS-DOS 7.00 et Windows 4.00 ; de même, Microsoft Windows 2000 Server est versionné en interne comme Windows NT 5.0 ("NT" étant une référence au nom de produit d'origine).
Python
La Python Software Foundation a publié PEP 440 - Version Identification and Dependency Specification, décrivant son propre schéma flexible, qui définit un segment d'époque, un segment de version, des segments de pré-version et de post-version et un segment de version de développement.
Texas
TeX a un système de numérotation de version idiosyncratique . Depuis la version 3, les mises à jour sont signalées par l'ajout d'un chiffre supplémentaire à la fin, de sorte que le numéro de version se rapproche asymptotiquement de π ; une forme de numérotation unaire - le numéro de version est le nombre de chiffres. La version actuelle est 3.14159265. Cela reflète le fait que TeX est très stable et que seules des mises à jour mineures sont prévues. Le développeur TeX Donald Knuth a déclaré que le "changement absolument final (à apporter après [sa] mort)" sera de changer le numéro de version en π , auquel cas tous les bogues restants deviendront des fonctionnalités permanentes.
De la même manière, le numéro de version de Metafont se rapproche asymptotiquement de e .
Pomme
À l'époque du Mac OS classique , les numéros de version mineurs allaient rarement au-delà de ".1". Quand ils l'ont fait, ils ont généralement sauté directement à ".5", suggérant que la libération était "plus importante". Ainsi, "8.5" a été commercialisé comme sa propre version, représentant "Mac OS 8 et demi", et 8.6 signifiait effectivement "8.5.1".
Mac OS X s'est écarté de cette tendance, en grande partie parce que "X" (le chiffre romain pour 10) était dans le nom du produit. En conséquence, toutes les versions d'OS X ont commencé par le numéro 10. La première version majeure d'OS X a reçu le numéro de version 10.0, mais la prochaine version majeure n'était pas la 11.0. Au lieu de cela, il a été numéroté 10.1, suivi de 10.2, 10.3, et ainsi de suite pour chaque version majeure suivante. Ainsi, la 11e version majeure d'OS X était étiquetée "10.10". Même si le "X" a été supprimé du nom à partir de macOS 10.12 , ce schéma de numérotation s'est poursuivi jusqu'à macOS 10.15. Dans le cadre du schéma de version basé sur "X", le troisième nombre (au lieu du deuxième) désignait une version mineure et des mises à jour supplémentaires en dessous de ce niveau, ainsi que des mises à jour d'une version majeure donnée d'OS X après la sortie d'un nouveau version majeure, étaient intitulées Mises à jour supplémentaires.
Le chiffre romain X a été utilisé simultanément à des fins de marketing sur plusieurs gammes de produits. Les deux QuickTime et Final Cut Pro est passé de la version 7 directement à la version 10, QuickTime X et Final Cut Pro X. Comme Mac OS X lui - même, les produits n'étaient pas mises à niveau des versions précédentes, mais les programmes flambant neufs. Comme avec OS X, les versions majeures de ces programmes ont incrémenté le deuxième chiffre et les versions mineures ont été notées à l'aide d'un troisième chiffre. Le « X » a été supprimé du nom de Final Cut avec la sortie de macOS 11.0 (voir ci-dessous), et la marque de QuickTime est devenue sans objet lorsque le cadre a été déprécié en faveur d'AVFoundation en 2011 (le programme pour lire la vidéo QuickTime n'a été nommé que QuickTime Player à partir de le début).
La prochaine version de macOS d'Apple, provisoirement numérotée 10.16, a été officiellement annoncée sous le nom de macOS 11.0 à la WWDC en juin 2020. La version suivante de macOS, macOS Monterey a été publiée lors de la WWDC 2021 et a fait passer son numéro de version principale à 12.
Microsoft Windows
Le système d'exploitation Microsoft Windows a d'abord été étiqueté avec des numéros de version standard pour Windows 1.0 à Windows 3.11 . Après cela, Microsoft a exclu le numéro de version du nom du produit. Pour Windows 95 (version 4.0), Windows 98 (4.10) et Windows 2000 (5.0), l'année de publication était incluse dans le titre du produit. Après Windows 2000, Microsoft a créé la famille Windows Server qui a continué le style basé sur l'année avec une différence : pour les versions mineures, Microsoft a ajouté le suffixe « R2 » au titre, par exemple, Windows Server 2008 R2 (version 6.1). Ce style était resté cohérent à cette date. Les versions clientes de Windows n'ont cependant pas adopté un style cohérent. Premièrement, ils ont reçu des noms avec des suffixes alphanumériques arbitraires comme avec Windows ME (4.90), Windows XP (5.1) et Windows Vista (6.0). Puis, une fois de plus, Microsoft a adopté des numéros incrémentiels dans le titre, mais cette fois, il ne s'agissait pas de numéros de version ; les numéros de version de Windows 7 , Windows 8 et Windows 8.1 sont respectivement 6.1, 6.2 et 6.3. Dans Windows 10 , le numéro de version est passé à 10.0 et les mises à jour ultérieures du système d'exploitation n'ont incrémenté que le numéro de build et le numéro de révision de build (UBR) de mise à jour.
Le successeur de Windows 10, Windows 11 , est sorti le 15 octobre 2021. Bien qu'elle porte le nom de "11", la nouvelle version de Windows n'a pas porté son numéro de version principale à 11. Au lieu de cela, elle est restée au même numéro de version de 10.0. , utilisé par Windows 10.
Autres régimes
Certains producteurs de logiciels utilisent des schémas différents pour désigner les versions de leurs logiciels. Le projet Debian utilise un schéma de version majeur/mineur pour les versions de son système d'exploitation, mais utilise les noms de code du film Toy Story pendant le développement pour faire référence aux versions stables, instables et de test.
BLAG Linux et GNU proposent des numéros de version très importants : les versions majeures ont des numéros tels que 50000 et 60000, tandis que les versions mineures augmentent le nombre de 1 (par exemple 50001, 50002). Les versions alpha et bêta reçoivent des numéros de version décimaux légèrement inférieurs au numéro de version principale, tels que 19999.00071 pour l'alpha 1 de la version 20000 et 29999.50000 pour la bêta 2 de la version 30000. À partir de 9001 en 2003, la version la plus récente en 2011 est 140000.
Urbit utilise la gestion des versions Kelvin (nommée d'après l' échelle de température Kelvin absolue ) : les versions du logiciel commencent à un nombre élevé et décomptent jusqu'à la version 0, moment auquel le logiciel est considéré comme terminé et aucune autre modification n'est apportée.
Numéros de version internes
Le logiciel peut avoir un numéro de version « interne » qui diffère du numéro de version indiqué dans le nom du produit (et qui suit généralement les règles de numérotation des versions de manière plus cohérente). Java SE 5.0, par exemple, a le numéro de version interne de 1.5.0, et les versions de Windows à partir de NT 4 ont continué les versions numériques standard en interne : Windows 2000 est NT 5.0, XP est Windows NT 5.1, Windows Server 2003 et Windows XP Professional x64 Edition sont NT 5.2, Windows Server 2008 et Vista sont NT 6.0, Windows Server 2008 R2 et Windows 7 sont NT 6.1, Windows Server 2012 et Windows 8 sont NT 6.2, et Windows Server 2012 R2 et Windows 8.1 sont NT 6.3, cependant, la première version de Windows 10 était 10.0 (10.0.10240). Notez, cependant, que Windows NT n'en est qu'à sa cinquième révision majeure, car sa première version était numérotée 3.1 (pour correspondre au numéro de version Windows de l'époque) et le lancement de Windows 10 a fait un saut de version de 6.3 à 10.0.
Versions préliminaires
En conjonction avec les divers schémas de gestion des versions répertoriés ci-dessus, un système de désignation des versions préliminaires est généralement utilisé, au fur et à mesure que le programme progresse à travers les étapes du cycle de vie de la version logicielle .
Les programmes qui sont à un stade précoce sont souvent appelés logiciels "alpha", après la première lettre de l'alphabet grec. Une fois qu'ils sont arrivés à maturité mais qu'ils ne sont pas encore prêts à être publiés, ils peuvent être appelés logiciels « bêta », après la deuxième lettre de l'alphabet grec. Généralement, les logiciels alpha sont testés uniquement par les développeurs, tandis que les logiciels bêta sont distribués pour les tests communautaires.
Certains systèmes utilisent des versions numériques inférieures à 1 (comme la 0.9), pour suggérer leur approche vers une version finale "1.0". Il s'agit d'une convention courante dans les logiciels open source . Cependant, si la version préliminaire est pour un progiciel existant (par exemple la version 2.5), alors un "a" ou "alpha" peut être ajouté au numéro de version. Ainsi, la version alpha de la version 2.5 peut être identifiée comme 2.5a ou 2.5.a.
Une alternative est de faire référence aux versions préliminaires en tant que "release candidates", de sorte que les packages logiciels qui seront bientôt publiés en tant que version particulière puissent porter cette étiquette de version suivie de "rc-#", indiquant le numéro de la release candidate. ; lorsque la version finale est publiée, la balise "rc" est supprimée.
Libérer le train
Un train de versions logicielles est une forme de calendrier de versions logicielles dans lequel un certain nombre de séries distinctes de versions logicielles versionnées pour plusieurs produits sont publiées sous la forme d'un certain nombre de « trains » différents selon un calendrier régulier. En règle générale, pour chaque ligne de produits, un certain nombre de trains de versions différents sont en cours d'exécution à un moment donné, chaque train passant de la version initiale à la maturité éventuelle et au retrait selon un calendrier planifié. Les utilisateurs peuvent expérimenter avec un train de versions plus récent avant de l'adopter pour la production, ce qui leur permet d'expérimenter des versions plus récentes, "brutes", tout en continuant à suivre les versions ponctuelles du train précédent pour leurs systèmes de production avant de passer au nouveau train de versions comme il devient mature.
La plate-forme logicielle IOS de Cisco a utilisé un calendrier de trains de versions avec de nombreux trains distincts pendant de nombreuses années. Plus récemment, un certain nombre d'autres plates-formes, dont Firefox et Fenix pour Android, Eclipse , LibreOffice , Ubuntu , Fedora, Python, digiKam et VMware ont adopté le modèle de train de versions.
Modifications du système numérique
Versions impaires pour les versions de développement
Entre les séries 1.0 et 2.6.x, le noyau Linux utilisait des numéros de version mineurs impairs pour désigner les versions de développement et même des numéros de version mineurs pour désigner les versions stables ; voir Noyau Linux § Numérotation des versions . Par exemple, Linux 2.3 était une famille de développement de la deuxième conception majeure du noyau Linux, et Linux 2.4 était la famille de versions stables dans laquelle Linux 2.3 a mûri. Après le numéro de version mineure dans le noyau Linux se trouve le numéro de version, dans l'ordre croissant ; par exemple, Linux 2.4.0 → Linux 2.4.22. Depuis la version 2004 du noyau 2.6, Linux n'utilise plus ce système et a un cycle de publication beaucoup plus court.
Le même système impair-pair est utilisé par d'autres logiciels avec des cycles de publication longs, tels que Node.js jusqu'à la version 0.12 ainsi que GNOME et WineHQ .
Importance politique et culturelle des numéros de version
La version 1.0 comme un jalon
Les communautés de logiciels libres et open source ont tendance à publier des logiciels tôt et souvent . Les versions initiales sont des nombres inférieurs à 1, ces versions 0.x étant utilisées pour indiquer que le logiciel est incomplet et pas assez fiable pour une publication générale ou utilisable dans son état actuel. Les modifications incompatibles avec les versions antérieures sont courantes avec les versions 0.x. La version 1.0 est utilisée comme un jalon majeur , indiquant que le logiciel possède au moins toutes les fonctionnalités majeures ainsi que les fonctions que les développeurs voulaient intégrer à cette version, et est considéré comme suffisamment fiable pour une publication générale. Un bon exemple en est le noyau Linux, qui a été publié pour la première fois en tant que version 0.01 en 1991, et a mis jusqu'en 1994 pour atteindre la version 1.0.0.
Les développeurs de l' émulateur de jeux d'arcade MAME n'ont jamais l'intention de sortir une version 1.0 du programme car il y aura toujours plus de jeux d'arcade à émuler et donc le projet ne pourra jamais vraiment aboutir. En conséquence, la version 0.99 a été suivie de la version 0.100.
Depuis qu'Internet s'est répandu, la plupart des éditeurs de logiciels commerciaux ne suivent plus la maxime selon laquelle une version majeure doit être "complète" et s'appuient plutôt sur des correctifs avec des corrections de bogues pour résoudre les problèmes connus pour lesquels une solution a été trouvée et pourrait être corrigée.
Numéros de version comme marketing
Une pratique relativement courante consiste à faire des sauts importants dans les numéros de version pour des raisons de marketing. Parfois, les fournisseurs de logiciels contournent simplement la version 1.0 ou publient rapidement une version avec un numéro de version ultérieur, car le logiciel 1.0 est considéré par de nombreux clients comme trop immature pour faire confiance aux déploiements de production. Par exemple, comme dans le cas de dBase II , un produit est lancé avec un numéro de version qui implique qu'il est plus mature qu'il ne l'est.
D'autres fois, les numéros de version sont augmentés pour correspondre à ceux des concurrents. Cela peut être vu dans de nombreux exemples de numérotation de version de produit par Microsoft, America Online , Sun Solaris , Java Virtual Machine , SCO Unix, WordPerfect . Microsoft Access est passé de la version 2.0 à la version 7.0, pour correspondre au numéro de version de Microsoft Word .
Microsoft a également été la cible d'un versionnage de "rattrapage", les navigateurs Netscape sautant la version 5 à 6, conformément à Internet Explorer de Microsoft , mais aussi parce que la suite d'applications Mozilla a hérité de la version 5 dans sa chaîne d' agent utilisateur pendant la version antérieure à la 1.0. développement et Netscape 6.x a été construit sur la base de code de Mozilla.
Un autre exemple de suivi de la concurrence est lorsque Slackware Linux est passé de la version 4 à la version 7 en 1999.
Abandon de l'élément le plus significatif
Java de Sun a parfois eu un système hybride, où le numéro de version interne a toujours été 1. x mais a été commercialisé par référence uniquement au x :
- JDK 1.0.3
- JDK 1.1.2 à 1.1.8
- J2SE 1.2.0 ("Java 2") à 1.4.2
- Java 1.5.0, 1.6.0, 1.7.0, 1.8.0 ("Java 5, 6, 7, 8")
Sun a également laissé tomber le premier chiffre pour Solaris, où Solaris 2.8 (ou 2.9) est appelé Solaris 8 (ou 9) dans les documents marketing.
Un saut similaire a eu lieu avec le kit de construction PBX open source Asterisk au début des années 2010, dont les chefs de projet ont annoncé que la version actuelle 1.8.x serait bientôt suivie par la version 10.
Cette approche, critiquée par beaucoup parce qu'elle brise la signification sémantique des sections du numéro de version, a été adoptée par un nombre croissant de fournisseurs, dont Mozilla (pour Firefox).
Superstition
- La version Office 2007 de Microsoft Office avait un numéro de version interne de 12. La version suivante, Office 2010, a une version interne de 14, en raison des superstitions entourant le numéro 13 . Visual Studio 2013 est le numéro de version 12.0 du produit, et la nouvelle version, Visual Studio 2015 a le numéro de version 14.0 pour les mêmes raisons.
- Roxio Toast est passé de la version 12 à la version 14, probablement dans le but d'éviter les superstitions entourant le nombre 13.
- Corel de WordPerfect Office , la version 13 est commercialisé comme "X3" ( numéro romain 10 et "3"). La procédure s'est poursuivie dans la prochaine version, X4. La même chose s'est produite avec la suite graphique de Corel (c'est-à-dire CorelDRAW , Corel Photo-Paint ) ainsi que son logiciel de montage vidéo "Video Studio".
- Sybase a ignoré les versions majeures 13 et 14 de son produit de base de données relationnelle Adaptive Server Enterprise, passant de 12.5 à 15.0.
- Le dictionnaire ABBYY Lingvo utilise la numérotation 12, x3 (14), x5 (15).
- SUSE Linux Enterprise a ignoré les versions 13 et 14 après la version 12 et a directement publié SLES 15 en juillet 2018.
Culture geek
- Le SUSE Linux la distribution a commencé à la version 4.2, pour faire référence à 42 «la réponse à la question ultime de la vie, l'univers et tout » mentionné dans Douglas Adams " Guide de la galaxie de l'auto - stoppeur .
- Une distribution Slackware Linux était version 13.37, faisant référence à leet .
- Finnix est passé de la version 93.0 à la version 100, en partie pour répondre à l'affirmation "There Will Be No Finnix '95", une référence à Windows 95 .
- La spécification Tagged Image File Format a utilisé 42 comme numéro de version interne depuis sa création, ses concepteurs ne s'attendant plus à le modifier au cours de leur (ou de sa) durée de vie car il serait en conflit avec ses directives de développement.
Surmonter les difficultés de marketing perçues
Au milieu des années 90, Maximo, la GMAO en croissance rapide , est passée directement de la série 3 de la série 3 à la série 5, ignorant la série 4 en raison des difficultés de commercialisation perçues de ce numéro sur le marché chinois, où le chiffre 4 est associé à la « mort » (voir tétraphobie ). Cela n'a cependant pas empêché la sortie de la version 4.0 de Maximo Series 5. (Le contrôle de version "Série" a depuis été abandonné, réinitialisant effectivement les numéros de version après la sortie de la version 1.0 de la série 5.)
Importance en génie logiciel
Les numéros de version sont utilisés en termes pratiques par le consommateur, ou client , pour identifier ou comparer sa copie du produit logiciel par rapport à une autre copie, telle que la version la plus récente publiée par le développeur. Pour le programmeur ou l'entreprise, la gestion des versions est souvent utilisée révision par révision, où des parties individuelles du logiciel sont comparées et mises en contraste avec des révisions plus récentes ou plus anciennes de ces mêmes parties, souvent dans un système de contrôle de version collaboratif .
Au 21e siècle, de plus en plus de programmeurs ont commencé à utiliser une politique de version formalisée, telle que la politique de gestion de version sémantique. Le but de telles politiques est de permettre aux autres programmeurs de savoir plus facilement quand les changements de code sont susceptibles de casser les choses qu'ils ont écrites. De telles politiques sont particulièrement importantes pour les bibliothèques et les frameworks de logiciels , mais peuvent également être très utiles à suivre pour les applications en ligne de commande (qui peuvent être appelées à partir d'autres applications) et en fait toute autre application (qui peut être scriptée et/ou étendue par des tiers ).
La gestion des versions est également une pratique requise pour activer de nombreux schémas de correctifs et de mise à niveau des logiciels, en particulier pour décider automatiquement vers quoi et où mettre à niveau.
Importance dans le support technique
Les numéros de version permettent aux personnes fournissant une assistance de déterminer exactement quel code un utilisateur exécute, afin qu'ils puissent exclure les bogues qui ont déjà été corrigés comme cause d'un problème, etc. Ceci est particulièrement important lorsqu'un programme a une communauté d'utilisateurs importante, en particulier lorsque cette communauté est suffisamment grande pour que les personnes fournissant le support technique ne soient pas les personnes qui ont écrit le code. La signification sémantique de la numérotation de style version.revision.change est également importante pour le personnel informatique, qui l'utilise souvent pour déterminer l'attention et la recherche qu'ils doivent accorder à une nouvelle version avant de la déployer dans leur établissement. En règle générale, plus les changements sont importants, plus les chances que quelque chose se brisent sont grandes (bien que l'examen du journal des modifications, le cas échéant, puisse ne révéler que des changements superficiels ou non pertinents). C'est l'une des raisons du dégoût exprimé par l'approche « abandonner la version majeure » adoptée par Asterisk et autres : désormais, le personnel doit (ou au moins devrait) effectuer un test de régression complet pour chaque mise à jour.
Numéros de version des fichiers et documents
Certains systèmes de fichiers informatiques , tels que le système de fichiers OpenVMS , conservent également des versions pour les fichiers.
La gestion des versions parmi les documents est relativement similaire à la routine utilisée avec les ordinateurs et le génie logiciel, où à chaque petit changement dans la structure, le contenu ou les conditions, le numéro de version est incrémenté de 1, ou d'une valeur plus petite ou plus grande, encore une fois en fonction de la préférence de l'auteur et la taille ou l'importance des modifications apportées.
Systèmes de commande de numéro de version
Les numéros de version évoluent très rapidement de simples entiers (1, 2, ...) à des nombres rationnels (2.08, 2.09, 2.10) puis à des "nombres" non numériques comme 4:3.4.3-2. Ces numéros de version complexes sont donc mieux traités comme des chaînes de caractères. Les systèmes d'exploitation qui incluent des fonctionnalités de gestion de packages (telles que toutes les distributions Linux ou BSD non triviales ) utiliseront un algorithme spécifique à la distribution pour comparer les numéros de version de différents packages logiciels. Par exemple, les algorithmes de classement de Red Hat et des distributions dérivées diffèrent de ceux des distributions de type Debian.
À titre d'exemple de comportement d'implémentation surprenant dans l'ordre des numéros de version, dans Debian, les zéros non significatifs sont ignorés par morceaux, de sorte que 5.0005 et 5.5 sont considérés comme égaux, et 5.5 < 5.0006. Cela peut dérouter les utilisateurs ; les outils de correspondance de chaînes peuvent ne pas trouver un numéro de version donné ; et cela peut provoquer de subtils bogues dans la gestion des packages si les programmeurs utilisent des structures de données indexées sur des chaînes telles que les tables de hachage indexées par numéro de version .
Pour faciliter le tri, certains progiciels représentent chaque composant du schéma major.minor.release avec une largeur fixe. Perl représente ses numéros de version sous forme de nombre à virgule flottante ; par exemple, la version 5.8.7 de Perl peut également être représentée par 5.008007. Cela permet à une version théorique de 5.8.10 d'être représentée comme 5.008010. D'autres progiciels emballent chaque segment dans une largeur de bits fixe ; par exemple, sur Microsoft Windows, le numéro de version 6.3.9600.16384 serait représenté sous la forme hexadécimale 0x0006000325804000. Le schéma à virgule flottante s'effondre si un segment du numéro de version dépasse 999 ; un schéma binaire compact utilisant 16 bits chacun tombe en panne après 65535.
Utilisation dans d'autres médias
Les numéros de version de style logiciel peuvent être trouvés dans d'autres médias.
Dans certains cas, l'utilisation est une analogie directe (par exemple : Jackass 2.5 , une version de Jackass Number Two avec des fonctionnalités spéciales supplémentaires ; le deuxième album de Garbage , intitulé Version 2.0 ; ou Dungeons & Dragons 3.5, où les règles ont été révisées depuis la troisième édition, mais pas au point d'être considérée comme la quatrième).
Le plus souvent, il est utilisé pour jouer sur une association avec la haute technologie, et n'indique pas littéralement une « version » (par exemple, Tron 2.0 , un jeu vidéo faisant suite au film Tron , ou la série télévisée The IT Crowd , qui fait référence au deuxième saison en version 2.0). Une utilisation particulièrement notable est le Web 2.0 , faisant référence aux sites Web du début des années 2000 qui mettaient l' accent sur le contenu généré par les utilisateurs , la convivialité et l' interopérabilité .