Question à propos des version et de l'assembly dans visual studio

Hello,

J'ai pris des renseignements mais j'ai quand même pas mal de mal à m'y retrouver. Avant je mettais alpha machin, bêta machin vu que bien souvent je ne publiais pas, je ne programmais que pour moi. J'ai peu fait de c# jusqu'a récemment j'étais sous python, java, c++ et php y'a un petit moment... au final je tapais ça bien souvent dans un fichier texte et du coup je commentais une partie pour m'y retrouver... Là je veux faire bien, j'ai publié une application, un plugin, les sources...donc je ne vais pas être seul ou en petit groupe de connaissances, du moins je l'espère...

Le gros update, la version principale, je présume que c'est sur l'ajout de nouvelles fonctions, voire une révision complète de l'interface ? (winform => wpf ou gros changement de l'interface ) ?
Mais la version secondaire je vois pas du tout...
Le numéro de build ??? C'est genre je me suis loupé en packant, je le refais ? et je change la version pour qu'on comprenne bien que cette version est plus complète ? S'il manque une dll, également ?
Le numéro de révision ? C'est pour les bugs corrigés ou bien c'est pour la version secondaire.

Comme toujours, merci d'avance aux experts et passionnés de ce forum, j'aimerai bien un jour renvoyer l'ascenseur en dépannant quelqu'un, je regarde de temps en temps, mais c'est souvent pointu.

Cordialement :D:D:D:D

Je rajoute ce que j'ai plu glaner à l'instant m'étant penché de nouveau sur la question, si ça peut servir à d'autres.. ça m'a permis d'y voir un peu plus clair, et je n'avais pas envisagé l'histoire de la rétrocompatibilité.

source: https://intellitect.com/making-sense...rsion-numbers/

Majeur: [...]Un numéro de version plus élevé peut indiquer une réécriture du projet sans que la rétrocompatibilité soit assurée.

Mineur: Si le nom et la version majeure du produit sont les mêmes, mais que la version mineure diffère, ça indique une amélioration significative avec rétrocompatibilité. Ce numéro de version plus élevé peut indiquer
une release ponctuelle d'un produit ou une nouvelle version totalement rétrocompatible.

Build: Une différence dans les numéros de builds représente une re-compilation des mêmes sources. Différents numéros de builds peuvent être utilisés lorsque le processeur, la plateforme, ou le compilateur changent.

Revision: [...]Un numéro de révision plus élevé peut être utilisé dans une version qui corrige une faille de sécurité dans un assembly précédemment publié.

Bonjour,

Il n'y a pas de règles absolues. Chacun fait ce qu'il souhaite.

Maintenant, les définitions que tu as trouvés sont souvent employées. A savoir :

• numéro majeur : un incrément indique une "révolution" dans le projet, avec une possible rupture de compatibilité. Par exemple PHP4, 5, 7. Python 2 et 3. Dans le sens changement révolutionnaire, il y a GIMP. La version 3 sera basé sur Gtk3 (changement de toolkit graphique). Qt 4 et 5 sont non compatible, et cela sera très certainement le cas avec Qt6
• numéro mineur : généralement, il s'agit d'une évolution. Principalement, ajout de fonctionnalités, mais sans toucher à la compatibilité
• numéro de révision ; correction de bugs (pas forcément de sécurité)
• numéro de build : comme son nom l'indique, lié à la compilation du projet (surtout utilisé dans le cas de nightly build, de beta, etc...) et très très très rarement gérer manuellement.

En guise de contre-exemple, on peut citer le noyau linux. De temps en temps, incrément du numéro majeur sans révolution. Ce fut le cas entre la version 1 et la version 2 du noyau. Sur un coup de tête, Linus a décidé de changer de version majeur. La version mineur devenait trop grande pour lui !

Il n'est pas rare non plus que le numéro mineur inclue des ruptures de compatibilité. Combien de fois j'ai eu des soucis avec ma Gentoo (ahh, la bonne époque) lors des mises à jour, car tel programme ne compilait pas avec une mise à jour d'une bibliothèque dont seul le numéro mineur avait changé, voir même le numéro de révision !).

Voilà, donc rien d'universel malheureusement. Mais se fixer des règles claires est souvent une bonne chose. Si en plus ces règles sont connues, reconnues et largement utilisées, autant en profiter.

Merci de ta réponse et de tes exemples, ça permet de rendre bien clair l'utilisation, je vais sauvegarder sous pdf comme mémo.