Quelqu'un pourrait-il m'indiquer où je peut trouver des infos sur la manière
de s'y prendre dans la gestion des numéros de versions.
Car je viens de démarrer une application. Alors, je dois lui donner quoi
comme numéro de version : 0.1.0.0 ? Et quand je dois passer à 0.2.0.0 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Ambassadeur Kosh
"ShadowFil" a écrit dans le message de news:
Bonjour,
Quelqu'un pourrait-il m'indiquer où je peut trouver des infos sur la manière de s'y prendre dans la gestion des numéros de versions. Car je viens de démarrer une application. Alors, je dois lui donner quoi comme numéro de version : 0.1.0.0 ? Et quand je dois passer à 0.2.0.0 ?
Majeure.Mineure.Build.Revision...
par exemple : - chaque fois que tu fais une modif dans le code (toi ou un membre de l'equipe), ça declenche (juste apres ou le soir), une compilation de l'ensemble. la tu changes la Revision. - apres plusieurs revisions, tout le monde se met d'accord pour livrer l'exe aux tests. apres livraison, tu augmentes le Build. - apres plusieurs build, ça devient satisfaisant, tout est fait, et on livre aux clients. la prochaine version commence, et la tu augmentes Mineur. - un pdg decide : "nous allons renforcer notre elan en synergisant les textbox en tons pastels", la tu augmente le Majeure :)
faut juste penser qu'un ensemble de tests sur une version peut parfois prendre plusieurs semaines. probleme relativiste que tout ceci, eh oui... tout cela a relier avec la notion de Label, et de Branche dans ton gestionnaire de sources
mais bon, ça c'est une façon de faire. il y'en a d'autres ou on ne se sert pas du Revision, d'autres ou on ne se sert que du M.m, et carrement d'autres ou la numerotation est différentes.
j'espere que ça te parle un peu ?
"ShadowFil" <ShadowFil@discussions.microsoft.com> a écrit dans le message de
news: 5062E265-04C3-423B-9E3E-B4278B911EFE@microsoft.com...
Bonjour,
Quelqu'un pourrait-il m'indiquer où je peut trouver des infos sur la
manière
de s'y prendre dans la gestion des numéros de versions.
Car je viens de démarrer une application. Alors, je dois lui donner quoi
comme numéro de version : 0.1.0.0 ? Et quand je dois passer à 0.2.0.0 ?
Majeure.Mineure.Build.Revision...
par exemple :
- chaque fois que tu fais une modif dans le code (toi ou un membre de
l'equipe), ça declenche (juste apres ou le soir), une compilation de
l'ensemble. la tu changes la Revision.
- apres plusieurs revisions, tout le monde se met d'accord pour livrer l'exe
aux tests. apres livraison, tu augmentes le Build.
- apres plusieurs build, ça devient satisfaisant, tout est fait, et on livre
aux clients. la prochaine version commence, et la tu augmentes Mineur.
- un pdg decide : "nous allons renforcer notre elan en synergisant les
textbox en tons pastels", la tu augmente le Majeure :)
faut juste penser qu'un ensemble de tests sur une version peut parfois
prendre plusieurs semaines. probleme relativiste que tout ceci, eh oui...
tout cela a relier avec la notion de Label, et de Branche dans ton
gestionnaire de sources
mais bon, ça c'est une façon de faire. il y'en a d'autres ou on ne se sert
pas du Revision, d'autres ou on ne se sert que du M.m, et carrement d'autres
ou la numerotation est différentes.
Quelqu'un pourrait-il m'indiquer où je peut trouver des infos sur la manière de s'y prendre dans la gestion des numéros de versions. Car je viens de démarrer une application. Alors, je dois lui donner quoi comme numéro de version : 0.1.0.0 ? Et quand je dois passer à 0.2.0.0 ?
Majeure.Mineure.Build.Revision...
par exemple : - chaque fois que tu fais une modif dans le code (toi ou un membre de l'equipe), ça declenche (juste apres ou le soir), une compilation de l'ensemble. la tu changes la Revision. - apres plusieurs revisions, tout le monde se met d'accord pour livrer l'exe aux tests. apres livraison, tu augmentes le Build. - apres plusieurs build, ça devient satisfaisant, tout est fait, et on livre aux clients. la prochaine version commence, et la tu augmentes Mineur. - un pdg decide : "nous allons renforcer notre elan en synergisant les textbox en tons pastels", la tu augmente le Majeure :)
faut juste penser qu'un ensemble de tests sur une version peut parfois prendre plusieurs semaines. probleme relativiste que tout ceci, eh oui... tout cela a relier avec la notion de Label, et de Branche dans ton gestionnaire de sources
mais bon, ça c'est une façon de faire. il y'en a d'autres ou on ne se sert pas du Revision, d'autres ou on ne se sert que du M.m, et carrement d'autres ou la numerotation est différentes.
j'espere que ça te parle un peu ?
ShadowFil
Cette méthode me paraît correcte après qu'on ait livré une première version. Mais, au tout début ?
Si on utilise une méthode itérative, on livre par exemple l'application tous les 3 mois. Comment affecter les numéros de versions et tomber juste à 1.0.0.0 à la release finale ?
Par exemple, si j'augmente le mineure tous les 3 mois (0.1.0.0, 0.2.0.0, 0.3.0.0, . . .), cela veut dire que je dois avoir 10 fois 3 mois pour tomber à 1.0.0.0 la 10ème fois. c'est un peu tordu comme raisonnement, mais c'est pour expliquer mon problème.
Cette méthode me paraît correcte après qu'on ait livré une première version.
Mais, au tout début ?
Si on utilise une méthode itérative, on livre par exemple l'application tous
les 3 mois. Comment affecter les numéros de versions et tomber juste à
1.0.0.0 à la release finale ?
Par exemple, si j'augmente le mineure tous les 3 mois (0.1.0.0, 0.2.0.0,
0.3.0.0, . . .), cela veut dire que je dois avoir 10 fois 3 mois pour tomber
à 1.0.0.0 la 10ème fois. c'est un peu tordu comme raisonnement, mais c'est
pour expliquer mon problème.
Cette méthode me paraît correcte après qu'on ait livré une première version. Mais, au tout début ?
Si on utilise une méthode itérative, on livre par exemple l'application tous les 3 mois. Comment affecter les numéros de versions et tomber juste à 1.0.0.0 à la release finale ?
Par exemple, si j'augmente le mineure tous les 3 mois (0.1.0.0, 0.2.0.0, 0.3.0.0, . . .), cela veut dire que je dois avoir 10 fois 3 mois pour tomber à 1.0.0.0 la 10ème fois. c'est un peu tordu comme raisonnement, mais c'est pour expliquer mon problème.
Ambassadeur Kosh
> Si on utilise une méthode itérative, on livre par exemple l'application tous les 3 mois. Comment affecter les numéros de versions et tomber juste à 1.0.0.0 à la release finale ?
jamais tu n'as 1.0.0.0 chez le client.
Par exemple, si j'augmente le mineure tous les 3 mois (0.1.0.0, 0.2.0.0, 0.3.0.0, . . .), cela veut dire que je dois avoir 10 fois 3 mois pour tomber à 1.0.0.0 la 10ème fois. c'est un peu tordu comme raisonnement, mais c'est pour expliquer mon problème.
tu commences à 0.0.0.0, tu evolues en interne 0.0.0.123, 0.2.512.892, et le jour ou tu decides de livrer tu estampille 1.0.0.0
mais bon, est-ce vraiment un probleme ?
> Si on utilise une méthode itérative, on livre par exemple l'application
tous
les 3 mois. Comment affecter les numéros de versions et tomber juste à
1.0.0.0 à la release finale ?
jamais tu n'as 1.0.0.0 chez le client.
Par exemple, si j'augmente le mineure tous les 3 mois (0.1.0.0, 0.2.0.0,
0.3.0.0, . . .), cela veut dire que je dois avoir 10 fois 3 mois pour
tomber
à 1.0.0.0 la 10ème fois. c'est un peu tordu comme raisonnement, mais c'est
pour expliquer mon problème.
tu commences à 0.0.0.0, tu evolues en interne 0.0.0.123, 0.2.512.892, et le
jour ou tu decides de livrer tu estampille 1.0.0.0
> Si on utilise une méthode itérative, on livre par exemple l'application tous les 3 mois. Comment affecter les numéros de versions et tomber juste à 1.0.0.0 à la release finale ?
jamais tu n'as 1.0.0.0 chez le client.
Par exemple, si j'augmente le mineure tous les 3 mois (0.1.0.0, 0.2.0.0, 0.3.0.0, . . .), cela veut dire que je dois avoir 10 fois 3 mois pour tomber à 1.0.0.0 la 10ème fois. c'est un peu tordu comme raisonnement, mais c'est pour expliquer mon problème.
tu commences à 0.0.0.0, tu evolues en interne 0.0.0.123, 0.2.512.892, et le jour ou tu decides de livrer tu estampille 1.0.0.0
mais bon, est-ce vraiment un probleme ?
java
Bonsoir,
C'est pas plutôt un problème moral (marketing) ?
Si tu livres une version 0.9.9.9 ton client il va pas aimer... il risque de se dire et zut j'ai payé pour un truc qui n'est pas terminé et ce même si ton application est au top. Par contre la version 1.0 ça fait mieux. Après une petite version 1.0.1.23 ça fait des plus sérieux car il va se dire il maintient bien mon application. A la sortie de la version 2.0 alors là il débouche la bouteille de champagne :-).
"ShadowFil" a écrit dans le message de news:
Cette méthode me paraît correcte après qu'on ait livré une première version. Mais, au tout début ?
Si on utilise une méthode itérative, on livre par exemple l'application tous les 3 mois. Comment affecter les numéros de versions et tomber juste à 1.0.0.0 à la release finale ?
Par exemple, si j'augmente le mineure tous les 3 mois (0.1.0.0, 0.2.0.0, 0.3.0.0, . . .), cela veut dire que je dois avoir 10 fois 3 mois pour tomber à 1.0.0.0 la 10ème fois. c'est un peu tordu comme raisonnement, mais c'est pour expliquer mon problème.
Bonsoir,
C'est pas plutôt un problème moral (marketing) ?
Si tu livres une version 0.9.9.9 ton client il va pas aimer... il risque de
se dire et zut j'ai payé pour un truc qui n'est pas terminé et ce même si
ton application est au top. Par contre la version 1.0 ça fait mieux. Après
une petite version 1.0.1.23 ça fait des plus sérieux car il va se dire il
maintient bien mon application. A la sortie de la version 2.0 alors là il
débouche la bouteille de champagne :-).
"ShadowFil" <ShadowFil@discussions.microsoft.com> a écrit dans le message de
news: 61B403F9-89DA-4A15-8775-E97F2C21248D@microsoft.com...
Cette méthode me paraît correcte après qu'on ait livré une première
version.
Mais, au tout début ?
Si on utilise une méthode itérative, on livre par exemple l'application
tous
les 3 mois. Comment affecter les numéros de versions et tomber juste à
1.0.0.0 à la release finale ?
Par exemple, si j'augmente le mineure tous les 3 mois (0.1.0.0, 0.2.0.0,
0.3.0.0, . . .), cela veut dire que je dois avoir 10 fois 3 mois pour
tomber
à 1.0.0.0 la 10ème fois. c'est un peu tordu comme raisonnement, mais c'est
pour expliquer mon problème.
Si tu livres une version 0.9.9.9 ton client il va pas aimer... il risque de se dire et zut j'ai payé pour un truc qui n'est pas terminé et ce même si ton application est au top. Par contre la version 1.0 ça fait mieux. Après une petite version 1.0.1.23 ça fait des plus sérieux car il va se dire il maintient bien mon application. A la sortie de la version 2.0 alors là il débouche la bouteille de champagne :-).
"ShadowFil" a écrit dans le message de news:
Cette méthode me paraît correcte après qu'on ait livré une première version. Mais, au tout début ?
Si on utilise une méthode itérative, on livre par exemple l'application tous les 3 mois. Comment affecter les numéros de versions et tomber juste à 1.0.0.0 à la release finale ?
Par exemple, si j'augmente le mineure tous les 3 mois (0.1.0.0, 0.2.0.0, 0.3.0.0, . . .), cela veut dire que je dois avoir 10 fois 3 mois pour tomber à 1.0.0.0 la 10ème fois. c'est un peu tordu comme raisonnement, mais c'est pour expliquer mon problème.
