Version imprimable
Bonjour à toutes zé à tous,
Je développe des applis et je souhaite leur attribuer une version (ex : 1.0).
Existe-t-il une nomenclature, une règle, un code qui gère le nommage des versions d'une appli (à partir de combien de mise à jour ou de modif change-t-on le n° de la version, etc...)
Merci de m'aiguiller sur un lien ou une piste !
Merci d'avance et bonnes fêtes à tous
BWeb
Salut.
Je ne crois pas qu'il existe réellement une "méthode" pour le versionnage, mais je peux te donner ma manière de procéder sur des versions à 4 chiffres (comme celles utilisées sous Windows).
Ce sont les plus complexes à gérer, donc si tu comprends comment ça marche, gérer des versions à deux chiffres sera un jeu d'enfant.
Un numéro de version est codé "M.m.r.b", avec :
- M : Version majeure.
- m : Version mineure.
- r : Révision (facultatif).
- b : Build, indice de construction (facultatif).
En pratique, le nombre "b" est soit incrémenté automatiquement par le compilateur, soit manuellement. En ce cas, se discipliner, et l'incrémenter au moins à chaque fois que l'entité compilée "sort" du poste de développement (à chaque publication).
Le nombre "r" est incrémenté lorsque l'on stabilise une version, c'est à dire que les tests unitaires (mais pas forcément les tests d'intégration) ont été réalisés complètement et que l'on publie l'entité. On s'en sert aussi, de manière annexe, pour indiquer des évolutions extrêmement mineures, comme des corrections de fautes d'orthographe ou des changements uniquement cosmétiques.
La version mineure "m" est incrémentée lors des ajouts de fonctionnalités, ou des corrections de bugs. La règle d'or dans ce cas est la compatibilité avec les versions précédentes : une version 1.2 doit être compatible avec une version 1.1 vis-à-vis des données qu'elles peuvent partager (fichier de configuration, structure des sauvegardes, etc...).
La version majeure est incrémentée dans plusieurs cas :
- Malgré peu de changements extérieurs au programme (IHM similaire, fonctionnalités identiques, etc...), le code source a été profondément modifié (au moins 1/3 du code refondu) => on change la majeure, car remanier le code a une raison, en général une amélioration de la stabilité, de la robustesse, de la vitesse et/ou une diminution des ressources nécessaires.
- De profondes améliorations, ou des ajouts de fonctionnalités importants rendent la nouvelle version incompatible (au moins partiellement) avec les précédentes.
Après, le choix d'incrémentation des valeurs dépend de ton goût personnel. Lors des phases d'essais, j'incrémente la révision de 1 à chaque bêta. Lors des corrections liées à des remontées de bugs, j'ai tendance à incrémenter directement de 5 (ex : 1.2.0.0 -> 1.2.5.0), pour "montrer" que l'on est à mi-chemin de la prochaine évolution mineure.
Pour les mineures, ça dépend du volume de corrections : si ce ne sont qu'une ou deux modifs légères, j'incrémente de 1. Si ce sont plusieurs modifications d'un seul coup, j'ai tendance à passer au multiple de 5 suivant (ex : 1.3.0.0 -> 1.4.0.0 -> 1.10.0.0).
Pour les majeures, c'est toujours une incrémentation "simple", d'une unité à chaque fois. Jamais de "saut" dans la numérotation.
Enfin, lorsque je développe un "nouveau" soft, je commence la numérotation à "0.0.0.0", je ne sors la "1.0.0.0" que lorsque le programme est totalement validé. De même, pour passer de la version 1.4.0.0 à la version 1.5.0.0, je commence par fabriquer une version "artificielle" 1.4.9.0 qui sera incrémentée "normalement" jusqu'à arriver à la version 1.5.0.0 une fois validée.
Pour les versions à deux chiffres, ce sont uniquement les champs "M" et "m" qui sont à prendre en compte, ce qui fait que la version mineure doit "prendre" les modifications des champs "r" et "b". Ca introduit souvent une augmentation assez démentielle du numéro de version mineure, mais bon : c'est un goût personnel...
Est-ce que ça répond à tes questions ?
Super !
merci de ta réponse très complète, je pense pouvoir sortir de tout ce que tu as écris une règle cohérente à suivre !
Merci encore
Bonnes fêtes
BWeb
Bonnes fêtes à toi aussi... Tu nous met un tag [Résolu] comme cadeau de Noël ? ;-)
sinon, tu fais comme ca
version 1, 2 3 95 98 me 2000 xp longhorn ;-)
sinon, le post de mac lak est complet et nikel ... pas grand chose a ajouter si ce n'est que moi en genéral je garde le quatrieme chiffre pour les corrections de securité (les seules qui sont faites au bou d'un moment sur un vieux logiciel)
Ce ujet est un petit peu vieux, mais en effectuant une recherche je suis tombé dessus.
Il y a une petite inversion entre N° de Build et de révision dans l'explication donnée.
Pour ceux qui font du .Net ouvrez un AssemblyInfo et vous verez de quoi je parle. C'est µSoft lui-même qui le dit.
:aie: :roll: :calim2:
y'a un p'tit pbe...
Un "build" c'est une compil...
Je ne vois pas en quoi on devrait mettre la compil avant la révision...
Tu fais une révision, et plusieurs builds pour cette révision..
Le principe sous-tendu par la numérotation est d'aller du moins précis au plus précis, de gauche à droite..
Tu fais une version majeure.. Pour cette version majeure plusieurs versions mineures.. Pour une de ces versions mineures plusieurs révisions.. Pour chaque réviison plusieurs compils..
Alors soit .net déroge à la régle générale, soit il y a qque chose de pas clair dans ta compréhension...
C'est en effet bizarre, j'ai du mal à comprendre pourquoi une revision est "plus petite" qu'une build, mais c'est apparemment comme ça qu'ils numérotent.
Peut-être qu'une build refère à une build de tout le projet et une révision à un changement d'urgence dans un sous-projet?
Il n'y aucune règle en la matière, mais la révision représente une correction dans une version mineure.
Un build, lui, est à la discrétion de l'éditeur, mais bien souvent il représente le n° de compilation depuis le tout début du projet. Un build n'est pas remis à 0 aux changements de version qu'ils soient majeur, mineur ou révision.
Mais encore une fois c'est chacun qui fait ce qu'il veut
µSoft peut s'être trompé, mais il écrit ça dans son fichier AssemblyInfo :
ici en vb, mais c'est pareil en c#.Citation:
' Version information for an assembly consists of the following four values:
'
' Major Version
' Minor Version
' Build Number
' Revision
'
' You can specify all the values or you can default the Build and Revision Numbers
' by using the '*' as shown below:
' <Assembly: AssemblyVersion("1.0.*")>
<Assembly: AssemblyVersion("1.0.0.0")>
<Assembly: AssemblyFileVersion("1.0.0.0")>
Il explique que chaque modification EST une révision, mais il n'est pas nécessaire de re-compiler à chaque fois. Lorsque toutes les corrections souhaitées sont faites, on compile et on livre.
ceci-dit, il semblerait que la majorité des gens fassent l'inverse il y a d'ailleurs ce sujet qui en parle.
ben oui, mais c'est idiot, parce que le "build" est censé indiqué la compilation de l'ENSEMBLE, pas de l'élément particulier... et ne dépend en rien 'une "livraison".. On peut faire des builds pour le banc de test par exemple....Citation:
Envoyé par kheironn
La dernière boite où j'étais un build par jour (nuit) pour le dev, un build pour le banc de test par semaine, un build pour mineure tous les 6 mois (sauf si bug), un build pour majeure par an.. (en moyenne)..
Et faire une modif , l'appeler "révision", et ne pas tester si ça compile, ça frôle les mauvaises pratiques... (sans même parler des effets de bord) :aie:
;) c''est bien ce quo'on disait...Citation:
Envoyé par kheironn