Que signifient réellement les versions de mise à jour?

18

De nombreuses mises à jour logicielles suivent le schéma de v0.1 à v0.2 à v2.6.5.6 . Que signifient réellement ces "mises à jour" du logiciel? Existe-t-il une norme industrielle toujours suivie ou les programmeurs continuent-ils à peu près d'augmenter la mise à jour # ou d'ajouter plus de décimales?

deployment software-updates software-distribution

— James Mertz
source

12

@ S.Lott Comme je suis relativement nouveau sur la scène de la programmation, je ne connais pas les spécificités. C'est la meilleure façon de demander que je puisse trouver.

— James Mertz

9

@ S.Lott, réduisez la consommation de caféine, ça vous rend irritable.

— ocodo

2

@ S.Lott n'hésitez pas à modifier comme bon vous semble pour améliorer la question. Je sens que tu sais ce que je cherche. Cependant, je pense que les réponses fournies ont été très bonnes. Je pense également, à en juger par les votes positifs de mon commentaire précédent, que j'ai fait de mon mieux et que la question est correcte en l'état. Cependant, je salue les critiques, ainsi que les modifications. Faites comme bon vous semble. Pour moi, je le laisse tranquille.

— James Mertz

1

@ S.Lott La question me semble assez claire comme ça. Je ne pense pas que l'inscription d'une organisation spécifique de normalisation serait une amélioration considérable. Si vous pensez le contraire, n'hésitez pas à modifier. Vous avez le représentant pour cela.

— Adam Lear

3

@ S.Lott: "Existe-t-il une norme industrielle"? Oui, il existe des normes industrielles! Peu importe qui les écrit: KronoS veut savoir ce que signifient les versions, c'est son choix de préciser le niveau de détail ... Peut-être auriez-vous dû mentionner que vous considérez la question trop large? Le simple fait de marteler les détails ne rend pas cela clair pour l'utilisateur, de dire à un utilisateur de définir: le mot ne le rend pas clair pour l'utilisateur, de dire que cela n'a aucun sens après que votre premier commentaire ne le rend pas clair pour l'utilisateur.

— Tamara Wijsman

16

Comme l'a dit Shaun, il n'y a pas vraiment de norme. Certaines sociétés ont de meilleures pratiques de versioning que d'autres (j'ai eu affaire à des fournisseurs qui ignorent les numéros de version principaux et d'autres qui sont bloqués sur le même xy plusieurs versions plus tard).

Cela dit, l'inventeur de Gravatars et cofondateur de GitHub ( Tom Preston-Werner ) est l'auteur d'un document pour « Semantic Versioning » qui vaut largement la peine d'être lu.

Voici l'exception de l'intro:

Pour résoudre ce problème, je propose un ensemble simple de règles et d'exigences qui dictent la façon dont les numéros de version sont attribués et incrémentés. Pour que ce système fonctionne, vous devez d'abord déclarer une API publique. Cela peut consister en une documentation ou être appliqué par le code lui-même. Quoi qu'il en soit, il est important que cette API soit claire et précise. Une fois que vous avez identifié votre API publique, vous lui communiquez les modifications avec des incréments spécifiques à votre numéro de version. Considérez un format de version de XYZ (Major.Minor.Patch). Les corrections de bugs n'affectant pas l'incrémentation de l'API de la version du correctif, les ajouts / modifications d'API rétrocompatibles incrémentent la version mineure et les modifications d'API incompatibles en arrière incrémentent la version principale.

J'appelle ce système «Versioning sémantique». Dans ce schéma, les numéros de version et la façon dont ils changent donnent une signification au code sous-jacent et à ce qui a été modifié d'une version à la suivante.

— Dan McGrath
source

7

Avec 4 chiffres, il s'agit généralement de MajorV.MinorV.PatchNum.BuildNum, au moins là où je travaille.

Personnellement, je préfère le schéma de version d'Ubuntu - rend la vie tellement plus facile.

— Emploi
source

Quel est leur schéma? Pourquoi les préférez-vous?

— James Mertz

3

Ubuntu 10.10 = octobre 2010, Ubuntu 10.04 = avril 2010, Ubuntu 11.04 = Aprial 2011, Ubuntu 9.10 = octobre 2009, etc. Ceci est mentionné dans ce lien Wikipedia de Shaun.

— Job

2

La bonne chose à propos de l'utilisation des dates comme numéros de version est que - à moins qu'un paradoxe étrange ne se produise - votre numéro de version sera toujours dans le bon ordre. Pour la plupart d'entre nous, il est plus facile de se rappeler qu'aujourd'hui est le 02.02.2011 que d'essayer de comprendre quelle version de la nouvelle version devrait être.

— jmort253

@ jmort245, exactement! Les systèmes créés par l'homme sont assez désordonnés. Les banques flippantes pensent qu'il y a 360, 362, 365, 366, etc. jours dans une année. Le système de version est encore une autre de ces créations stupides. Les horodatages ne nous font pas réfléchir, bien que 20050207 prenne un peu plus de temps à lire et à comprendre que 502. Quel logiciel sort plus d'une fois par mois?

— Job

2

@job: Mais l'utilisation de versions vous permet de lier des fonctionnalités à des versions majeures ou mineures spécifiques. Donc, si j'ai la version 2, je sais que j'ai la fonctionnalité X alors que la version 1 n'a pas la version X.

— Martin York

6

La version courte est qu'il n'y a pas de norme et que les entreprises font ce qu'elles veulent. Essentiellement, plus vous avez de nombres, plus la quantité de changements que chaque nombre représente est petite. Généralement, vous verrez au moins la version xy, où un changement de x dans x signifie des versions majeures (améliorations majeures / déploiements de fonctionnalités) et y signifie des versions mineures (ajustements importants ou corrections de défauts). Plus de décimales après ces deux éléments peuvent signifier différentes choses en interne pour une entreprise, bien qu'elles tournent souvent autour de versions ou de correctifs de contenu mineurs qui représentent des correctifs plus rapides et plus petits.

Wikipedia a un article qui couvre cela plus en détail.

— Shaun
source

3

Le but des numéros de version est de fournir une référence pour les rapports de problèmes. La seule exigence est que chaque version ait un numéro de version unique. Certains nombres sont dictés par le marketing - des nombres entiers plus grands sont plus faciles à vendre, et des nombres de puissance comme 10 (chiffre romain X) sont vraiment accrocheurs. Certaines personnes utilisent une variante du versioning sémantique:

MAJOR.MINOR.MICRO.BUILD

Incréments majeurs: modifications incompatibles ou refonte complète de l'interface utilisateur
Incréments mineurs: nouvelles fonctionnalités ajoutées, compatibles avec les versions précédentes dans le même numéro de version principale
Micro incréments: version de correction de bogue
Numéro de build: généré par le compilateur ou extrait du contrôle de version

De nombreux groupes abandonnent le numéro BUILD dans leurs versions. Il n'est généralement utile qu'entre les groupes de test et de développement.

Certains groupes ajoutent des sémantiques supplémentaires, telles que les incréments MINOR impairs sont pour les versions expérimentales et les incréments MINOR pairs sont pour les versions de production (le noyau Linux utilise cette approche).

L'essentiel, c'est qu'il n'y a pas de norme, à part que les versions plus récentes utilisent des numéros de version plus élevés et que chaque numéro de version est unique.

— Berin Loritsch
source