Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Comment nommer les versions d'une application
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 ?
Mac LAK.
___________________________________________________
Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.
Sources et composants Delphi sur mon site, L'antre du Lak.
Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.
Rejoignez-nous sur : ► Serveur de fichiers [NAS] ► Le Tableau de bord projets ► Le groupe de travail ICMO
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 ? ;-)
Mac LAK.
___________________________________________________
Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.
Sources et composants Delphi sur mon site, L'antre du Lak.
Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.
Rejoignez-nous sur : ► Serveur de fichiers [NAS] ► Le Tableau de bord projets ► Le groupe de travail ICMO
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.
En informatique, le problème se situe toujours entre le clavier et l'écran !
Il y a deux chemins entre le clavier et l'écran : Par l'UC et par l'utilisateur.
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...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
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?
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
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
--- Sevyc64 ---
Parce que le partage est notre force, la connaissance sera notre victoire
µSoft peut s'être trompé, mais il écrit ça dans son fichier AssemblyInfo :
ici en vb, mais c'est pareil en c#.' 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.
En informatique, le problème se situe toujours entre le clavier et l'écran !
Il y a deux chemins entre le clavier et l'écran : Par l'UC et par l'utilisateur.
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....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)
c''est bien ce quo'on disait...
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager