Date en tant que numéro de version du logiciel

Les développeurs de logiciels n'utilisent généralement pas la date comme numéro de version, bien que le format AAAAMMJJ (ou ses variantes) semble suffisamment solide pour être utilisé. Y at-il quelque chose de mal avec ce régime? Ou s'applique-t-il uniquement à des "types" de logiciels limités (comme des productions internes)?

C’est quelque chose que vous allez devoir examiner sous différents angles, car vous devez prendre en compte les besoins des utilisateurs, ainsi que ceux du logiciel et des développeurs.

En général, vos clients ne se soucient pas beaucoup du numéro de version du logiciel tant qu'ils savent qu'ils exécutent quelque chose de plus récent (c'est-à-dire que Produit 2012 est plus récent que Produit 2010) et qu'ils le savent. est à jour s'il existe des correctifs pouvant être déployés (par exemple, Product 2012, Update 10). En tant que tel, du point de vue de la marque du client, j'ai tendance à préférer une version nommée (par exemple Windows XP, Windows Vista) suivie d'un nombre de séquences strict de correctifs pouvant être installés par les utilisateurs.

Cela dit, un logiciel d’écriture qui vérifie les choses faciles pour l’utilisateur tend à rendre le code sous le capot beaucoup plus difficile à écrire. Ainsi, j'ai tendance à préférer le Major.Minorschéma de version simple, ne serait-ce que parce que vous pouvez effectuer une simple comparaison de nombres pour vérifier que quelque chose est à jour, comme dans ce qui suit:

// Check to see if we can handle the file version
if (this.Version < fileVersion) {
   throw new UnsupportedFileException("The file version is " + fileVersion.toString() + " which is not supported");
}
// Do stuff ...

Pour mettre cela dans un peu de contexte, je me fiche généralement de l’importance du nombre mineur (ie 1.1024), ce qui permet au système ci-dessus de continuer à fonctionner avec succès. En règle générale, les numéros de révision ne concernent que le développement interne et je ne les ai même pas vraiment vus affecter des choses qui vont bien au-delà d'une simple numérotation supplémentaire à suivre.

Cependant, les deux schémas ci-dessus ne s'appliquent vraiment qu'aux environnements dans lesquels le déploiement continu est utilisé (c.-à-d. Stack Exchange), c'est pourquoi j'ai tendance à préférer une sorte de date suivie d'un numéro de révision, ce qui semble être utilisé sur Stack Exchange. des sites. La raison en est que les versions vont trop souvent changer dans l'environnement de déploiement continu et que plusieurs versions du code peuvent apparaître le même jour, ce qui justifie le numéro de révision et que la date actuelle est aussi bonne que pour briser des choses. encore plus. En théorie, vous pouvez simplement utiliser le numéro de révision pour tout, mais utiliser la date du jour vous permet de garder une trace interne des jalons majeurs qui pourraient rendre les choses plus faciles à discuter.

Le problème avec l'utilisation d'une date, c'est que les spécifications sont écrites par rapport aux nombres de comptage plutôt qu'à une date d'échéance.

"Cette fonctionnalité devrait être dans la version 1. L'autre fonctionnalité devrait être dans la version 2."

Vous ne pouvez pas faire référence à une date dans les spécifications, car la date de publication pourrait être manquée.

Si vous ne disposez pas d'un tel processus formel nécessitant l'identification préalable de différentes versions, l'utilisation de dates convient. vous n'avez pas besoin d'ajouter un autre numéro au mélange.

Il est peu probable que les numéros de version contiennent des dates, car leur contexte est lié à des spécifications.
Les numéros de build sont susceptibles de contenir des dates, car leur contexte est lié au moment où la build a eu lieu.

Bien que cette approche présente les avantages que vous avez décrits, il existe certains inconvénients si vous utilisez date comme numéro de version:

• Les versions basées sur la date sont plates. Avec v2.1.3, vous pouvez voir le numéro de version, le numéro de version et le numéro de sous-version. Avec 20110119, vous pouvez seulement voir quand il a été écrit. Vous pouvez regrouper vos versions datées par mois, mais cela ne vous dit toujours rien. Vous pourriez avoir plusieurs mois lents de résolution de bugs mineurs, puis deux semaines de codage intensif aboutissant à une version majeure. Les dates ne vous le disent pas, contrairement aux numéros de version normaux.

• Si vous avez vraiment besoin de changer la version quotidiennement et éventuellement le numéro de version, cela peut indiquer que vous ne disposez pas du processus de publication approprié, mais que tout le monde change radicalement de contenu et le promeut sur les serveurs de production à tout moment. Si tel est le cas, vous rencontrez un problème avec le processus et l'utilisation d'un schéma de numéro de version différent ne résoudra pas le problème.

Les versions sont souvent utilisées pour transmettre des informations sur la différence d'une version du logiciel par rapport à la version précédente. Ainsi, par exemple, si vous effectuez une mise à niveau de la version 1.0 à la version 2.0 d'Acme, il s'agit d'une mise à niveau majeure, qui implique en théorie des modifications majeures.

Une mise à niveau de 1.0 à 1.1, en revanche, est une mise à niveau mineure et comporte en théorie des modifications mineures, incrémentielles et des corrections de bugs.

Ce serait difficile à représenter dans un format de date, bien que vous puissiez utiliser un mélange. Par exemple, v1.0.YYYY.MMDD

Sans reprendre les bonnes idées d'autres réponses, j'ai un problème en tête qui n'a pas encore été abordé.

Si vous faites un fork, entre une version plus ancienne pour la compatibilité ascendante et une nouvelle version pour une modernisation incompatible, vous ne pouvez pas les distinguer via les numéros de version.

Par exemple, le noyau Linux a été introduit vers l’an 2000 dans l’ancienne branche 2.4.x, qui est probablement encore prise en charge aujourd’hui et porte le numéro 2.4.199, alors que la nouvelle version est la version 2.6 depuis de nombreuses années et correspond à 2.6.32. pour les systèmes plus anciens, mais 3.2 pour les derniers noyaux.

Si vous avez de la documentation sur vos versions, vous doublez les informations et informez les gens que la version 20120109 est arrivée en 2012 au 01/09. Mh. Mais quoi, s'il y a une détection de bogue au dernier moment, et qu'une publication est retardée d'une semaine, mais que la documentation, où le nom est mentionné, est déjà prête, peut-être imprimée, les informations de presse sont publiées, etc. Vous avez maintenant une divergence qui pose problème si la version 20120109 est arrivée au 13/01/2012.

En SQL, la question de savoir si les identifiants doivent porter des informations sémantiques a souvent été discutée, et le résultat est toujours: évitez-les comme un diable! Vous créez une dépendance inutile. Cela ne peut pas être bénéfique.

Ubuntu avec son schéma 04/10 avait son problème en 2006, lorsque la version 6.04 a été retardée et est devenue 6.06. En l'an 3000, il y aura bientôt le prochain problème! :)

Il existe de nombreux logiciels qui utilisent effectivement la date comme version. On pense à Ubuntu, où leur version est AA.MM. Et les numéros de build pour les produits Microsoft Office sont également un encodage de la date de build. Jeff Atwood a écrit un article de blog de Coding Horror sur la numérotation des versions , y compris cette recommandation:

Dans la mesure du possible, utilisez des dates simples au lieu des numéros de version, en particulier dans les noms publics des produits. Et si vous devez absolument utiliser les numéros de version en interne, indiquez-les quand même: assurez-vous d’encoder la date de la construction quelque part dans votre numéro de version.

À mon avis, cela n'a pas d'importance tant que vous êtes cohérent et que vous pouvez utiliser un numéro de version de compilation (quel qu'il soit) et rappeler tous les artefacts ayant été intégrés à cette version à partir de votre système de contrôle de version. Les utilisateurs ne se soucient généralement pas des informations de version, mais des fonctionnalités fournies par le système. Les informations de version n'ont qu'une valeur réelle pour les développeurs.

Utilisez le versioning sémantique - de cette façon, vous aurez une idée du type de modifications apportées entre les versions sans avoir à inspecter le code lui-même: http://semver.org/

Utiliser les numéros de version est un moyen de montrer à quel point le changement est BIG

Par exemple, 2.4.3 peut signifier que la version 2 est le changement majeur apporté à l’ensemble du système. .4 est une mise à jour mineure. et le dernier .3 est un petit correctif pour cette version. De cette façon, il est facilement reconnaissable combien a changé entre chaque version.

Cela dit, je vois encore beaucoup de gens utiliser des dates ou des numéros de révision SCM comme numéros de version, tant que vous avez un moyen de retracer les notes de publication et la documentation de ce qui était visé par cette version, il n'y a pas de réel problème.

Quelques bonnes réponses ici déjà, mais je voudrais signaler un cas où l'utilisation de dates est parfaitement logique: de petites bibliothèques ou des fragments de code où le code est susceptible d'être mis à jour fréquemment mais par petits morceaux sans aucune version différente qui diffère de façon spectaculaire de la précédente une.

En d'autres termes, je parle de situations dans lesquelles il n'y a pas de "numéro de version" mais plutôt une sorte de vidage de dépôt quasi quotidien.

Quand je rencontre ce genre de choses, je me félicite généralement de ce choix car il m'est plus utile de savoir que j'utilise un script / lib relativement récent plutôt qu'une version spécifique.

Les dates en tant que numéro de version sont bonnes pour le marketing. Si les gens utilisent "Windows NT 5.0", ils ne se rendront peut-être pas compte qu’il est obsolète. Mais si les utilisateurs utilisent encore "Windows 2000", ils sauront instantanément qu'il s'agit d'un système d'exploitation vieux de 12 ans et seront encouragés à effectuer la mise à niveau.

Cependant, cela rend plus difficile la distinction entre les mises à jour "majeures" et "mineures".

Problème avec l'utilisation de dates comme numéros de version

Les réponses ici sont bonnes, mais je n’ai vu personne régler ce problème en utilisant des dates: l’utilisateur ne peut pas déterminer la fréquence à laquelle les modifications ont été apportées.

Ce que j'essaie de dire, c'est que je peux dire que Windows 3.1 et Windows 7 sont très éloignés les uns des autres ... et sont peut-être incompatibles. Windows 95 et Windows 2000 ne me disent rien de plus que l'année du lancement du produit.

Par exemple, avec Python, je sais que la version 2.7.2 a évolué depuis la version 2.4.6. Si je regarde plus loin, je vois que la version 2.4.6 a été publiée le 19 décembre 2008; et cette version 2.7.2 a été publiée le 11 juin 2011. À partir de là, je peux me faire une opinion sur la stabilité (c'est-à-dire la fréquence de publication) d'un produit.

Si, au lieu de cela, Python avait utilisé les dates de publication, je ne saurais pas comment ces produits pourraient être connectés. Cela créerait une confusion supplémentaire, car Python 3.1.4 a également été publié le 11 juin 2011 (identique à Python 2.7.2).

En bref, je ne pense pas que, par lui-même, le versioning de date soit utile.

Je n'aime pas cette idée, pour des raisons déjà décrites par d'autres. Utilisez simplement le schéma major.minor.bugfix - il y a une raison pour laquelle la plupart des gens le font de cette façon.

Mais quoi que vous fassiez: choisissez un schéma de nommage de version et respectez-le . Ne le faites pas comme Windows, où ils modifient le schéma à chaque version. Et ne le faites pas comme Android, où chaque version a un numéro de version d'API (8), un numéro de version destiné au marketing (2.2) et un nom stupide (Froyo).

Date comme version

Si votre produit n'est pas vendu, alors simplement utiliser la date est utile et probablement utile. Si vous le vendez et que vous le mettez à niveau, les clients souhaitent acheter un modèle doté d'un ensemble de fonctionnalités spécifiques. Il est beaucoup plus facile de les vendre sur une mise à niveau si ce modèle porte un nom clair. Peu importe ce que c'est, mais par exemple, personne n'achète réellement la voiture Ford du 20 janvier 2012 et souhaite le modèle Kia. La même chose est vraie du logiciel. Donner un nom et une version de modèle précis signifie que ses fonctionnalités sont différentes de celles des anciennes. Pour moi, juste une date ne fait pas cela, il dit que je l'ai fait alors, il pourrait ne pas avoir de nouvelles fonctionnalités.

Schéma que nous utilisons

Je n'ai pas prétendu que notre système crée une marque claire comme ci-dessus. Nous utilisons maintenant un schéma en quatre parties. Un numéro de version, l'état, la date et une somme de contrôle.

1200_GLD_120120_F0D1

Cela peut paraître exagéré, mais cela nous permet d’avoir plusieurs versions de la version pour la version 1200 que nos ingénieurs peuvent utiliser et nous les différencions par date. L' État indique aux utilisateurs s'il s'agit d'une version de test interne, d'une version de correctif client ou d'une version Gold. La somme de contrôle est nouvelle, elle permet à un ingénieur ou à un client de vérifier qu’il a bien téléchargé le bon fichier de notre distribution.

Donc, nous pourrions avoir une séquence de

1200_TST_120110_EF45
1200_GLD_120120_F0D1
1201_FIX_120125_123E
1201_TST_120130_31A5
1201_TST_120131_FDFD

Nous nous référons normalement aux numéros de version majeurs au client, par exemple "12", mais un client obtiendra la dernière version or de 12, à savoir 1200_GLD_120120_F0D1, sauf s'il a besoin du correctif.

Supposons que certains clients utilisent la version deux de votre produit et que certains ont mis à niveau leur version 3. Cette mise à niveau n’est pas une décision prise à la légère.

Supposons que la dernière version de la version deux est 2.3.2 et que la version trois est 3.0.3. Maintenant que vous trouvez une vulnérabilité qui doit absolument être corrigée, vous publiez les versions 2.3.3 et 3.0.4 le même jour. Pouvez-vous voir en quoi la date de sortie est totalement hors de propos? Vous avez peut-être arrêté de travailler sur la version deux en 2013 et publié seulement quelques corrections de bogues essentielles depuis. La date est sans importance par rapport au numéro de version.

Je pense que ça marche très bien. Je l'utilise pour certains logiciels internes (aaaa.mm.jj) et pour certains logiciels open source que j'ai publiés.

Cela peut ne pas fonctionner dans tous les cas.

Techniquement, il ne peut pas utiliser la date pour le numéro de version, mais il pourrait afficher le numéro de la date pour le client. Par exemple, macOS 16.7.23 --- cela signifie que: 23/07/2016

Je pense que la technologie n'est pas le problème, mais le problème, c'est comment on se sent? Si vous utilisez un numéro de date qui pourrait rendre un logiciel vivant, comme un homme qui fête son numéro d'anniversaire.

Le numéro du bâtiment ressemble à la machine, la machine, pas de vie, pas de vie.