Pourquoi System.Version dans .NET est-il défini en tant que Major.Minor.Build.Revision?

Pourquoi System.Version dans .NET est-il défini en tant que Major.Minor.Build.Revision? Presque tout le monde (y compris moi-même) semble être d’accord pour dire que la révision appartient à la troisième place et que «build» ou tout ce que vous aimeriez appeler, appartient en dernier.

Microsoft utilise-t-il même les chiffres de cette manière aléatoire, par exemple 3.5.3858.2, ou les noms eux-mêmes sont-ils simplement inversés? Par exemple, si vous deviez écrire votre propre classe Version avec la commande Major.Minor.Build.Revision, serait-il approprié d’échanger les deux derniers composants lors de la conversion vers System.Version, ou l’ignorez-vous et faites-vous simplement semblant sont en arrière?

Je pense que la confusion vient ce que la plupart considèrent comme une “révision” et ce que fait Microsoft :

  • Build: une différence de numéro de build représente une recompilation de la même source. Cela serait approprié en raison des modifications apscopes au processeur, à la plate-forme ou au compilateur.

  • Révision: Les assemblys portant le même nom, les numéros de version majeurs et mineurs, mais des révisions différentes, sont destinés à être entièrement interchangeables. Cela serait approprié pour réparer un trou de sécurité dans un assemblage précédemment libéré.

L’angle des points de sécurité, probablement beaucoup plus courant pour eux, semble être une bonne raison de le placer au dernier rang, en tant que changement “le plus mineur”.

Je me rends compte que je viens à la fête un peu tard, mais je voulais partager ma double raison pour laquelle l’ordre de construction et de révision est “faux”. Ce n’est pas tellement qu’ils sont dans le mauvais ordre, mais qu’ils ne sont dans aucun ordre.

La version d’un assemblage, en fin de compte, est Major.Minor. D’après le lien susmentionné, Microsoft déclare: “Les versions ultérieures d’un assembly qui diffèrent uniquement par des numéros de version ou de révision sont considérées comme des mises à jour de correctif de la version précédente.” [Mon accent]

La construction représente une recompilation de la même source. La révision représente un changement de code, mais il est totalement interchangeable avec les autres révisions de la même version [Major.Minor]. Mais ni l’un ni l’autre n’a préséance sur l’autre.

Donc, en résumé, ne le considérez pas comme:

 + Major | +-+ Minor | +-+ Build | +-+ Revision 

Mais plutôt:

 + Major | +-+ Minor | +-+ Build | +-+ Revision 

Microsoft utilise-t-il même les nombres de cette manière aléatoire, par exemple, 3.5.3858.2

Si vous le laissez par défaut, par exemple en spécifiant [assembly: AssemblyVersion("1.1.*")] , Le troisième nombre augmente chaque jour, et le quasortingème nombre représente le nombre de secondes écastings depuis minuit, plus d’un construit en un seul jour).

Presque tout le monde (y compris moi-même) semble être d’accord pour dire que la révision appartient à la troisième place et que «build» ou tout ce que vous aimeriez appeler, appartient en dernier.

Microsoft semble utiliser “build” comme synonyme de “day”: c’est peut-être lié à l’idée de “builds quotidiens”; et une “révision” est donc une autre version de la construction (quotidienne).

Réponse tardive, mais je pense que les autres réponses pourraient être élargies un peu.

Les termes “build” et “revision” ne sont que la terminologie Microsoft. La classe System.Version ne se soucie en aucune façon de leur atsortingbution.

Pour ce qui est de changer l’ordre des pièces pour correspondre à votre propre terminologie, je dirais que vous devriez ignorer complètement les mots et plutôt considérer ce que la System.Version définit vraiment :

  • Un format de chaîne qu’il peut parsingr et générer:

     major.minor[.build[.revision]] 

    Cela signifie que si vous avez l’habitude de posséder votre propre version au format xyzw, vous devez instancier la classe Version de la manière suivante:

     new Version(x, y, z, w) 

    Tout autre ordre de paramètre ne correspondra pas à ce que feraient Parse () et ToSsortingng (). Si vous changez z et w, alors ToSsortingng () afficherait xywz, ce qui serait déroutant pour tout le monde si vous attendez xyzw

  • Une comparaison de versions et un ordre de sorting , selon lesquels les versions sont sortingées d’abord par majeur, puis par mineur, puis par construction, puis par révision, comme la plupart d’entre nous le souhaitent. C’est-à-dire que 1.2.5 est postérieur à 1.2.3.7.

    Donc, si vous atsortingbuez la valeur 1.2.6.4 à votre chaîne de version et que vous souhaitez que cette chaîne soit considérée comme plus récente que la version 1.2.5.8, ne changez pas l’ordre des parties dans le constructeur Version.

En bref – bien que les mots major / minor / build / revision puissent donner une idée du nombre à augmenter compte tenu de l’importance des changements, la terminologie a très peu d’impact sur la manière dont la classe est réellement utilisée. Le formatage et le sorting sont ce qui compte.