Je voulais savoir comment ca marche l'atribution des numero pour les version,c'est a dire 0.1,version 0.1a, 0.1b 0.1rca etc..
Ya des log qui avance de 1 en 1,d'autre de 0.1 en 0.1 et d'autre son de plusieurs numero 0.0.1.0.2    
 
vous pouvez m'eclairer?  

Ça l'intéresse aussi et moi aussi mais je pense pas qu'il y ait de règles, on fait comme bon nous semble..

 
oue mais version alpha,beta,rca,si ca existe,c'est qu'il doit y avoir une norme,sinon on ne mettrait que des numero.C vrai que l'on fait ce que l'on veut,mais ca fait plus pro si on suit de normes

 
tout dépend des logiciels, de l'ouverture au public, du nombre d'utilisateurs, etc ...
 
une version alpha c'est une ébauche ave des trucs fonctionnels. Beta c'est une version "finale" mais qui comporte encore probablement des bugs ...  
 
Pour les numéros je ne pense pas qu'il y ait une norme mais je peux me tromper

Y a des 1.01, ou 3.01.23 etc... Ca doit dépendre de l'organisation du développeur et de ses règles de travail ?
 
Il me semble que qq part quelqu'un en parlait, pour distinguer les révisions majeurs et mineures.  
 

et vous qui devellopez,vous faites comment?

 
sincèrement. Je me préoccupe pas du tout de ça pour le truc dont je m'occupe actuellement et je pense que je devrais ...
 
En fait on utilise CVS et je tague l'arbre au moment où je fais une release et donc j'ai un numéro de version sous forme de timestamp. Vraiment pas élégant, surotut pour la doc. Le prob c'est que tu as à peine le temps de mettre la doc à jour qu'elle est déjà out of date ...

 
je pense aussi que c'est un moyen au programmeur de s'y retrouver dans les otpions qu'il a fait et dans les truc qu'il doit faire.Il se fixe un objective pour tel ou tel version et il code.
Pour les grandes boites c'est aussi un argument de vente,car par exemple netscape a fait la version 6 sans faire la version 5 pour devancer internet explorer 5.
 
Mais si qq sait qqchose la dessu,qu'il nous fassent signe  

 
a.b.c.d
 
a = très gros changements dans l'architecture ou les fonctionnalités du soft
b = grosses fonctionnalités ajoutées
c = petits détails
d = bug fix / changements mineurs (pas de nouvelles fonctionnalités)
d étant le build ID, chaque fois que je recompile le soft pour en faire une version distribuée je l'incrémente, même s'il n'y a qu'une ligne de code qui a changé.

Souvent sous Linux :
a.b.c
a = très gros changements dans l'architecture ou les fonctionnalités du soft
b = grosses fonctionnalités ajoutées ou nouvelle fonctions ajoutées ou corrections de nombreux bugs (si b paire -> stable, par contre si b impaire -> instable)
c = corrections de bugs
 
(ça se peut que je me sois tromper sur quelques détails, mais en gros c'est le principe).
 
Le "a" dépend beaucoup du programmeurs certains programmes sont toujours avec un a égal à 0, bien que ces projets bougent pas mal. Ou des fois il est très dur de savoir si il faut incrémenter le a, par exemple sur les gros projets, comme le noyaux Linux, ou certains seraient bien tenter de passer à la version 3, alors que d'autres veulent passer à la 2.6 (comme Linus).

Je commence a me faire une meilleur idéé sur les numerotation des logiciel.
 
Ca veut dire quoi rca,car j'ai deja vu ca pour le ogg vorbis.

Release CAndidate très probablement..

Precisons que pour linux, les 2.x ou x est pair sont le snoyeaux stables et les 2.x ou x est impair sont les noyeaux instables en developement

 
ok  

pour ceux qui font des script php,vous mettez des version?

intéressant ce topic ...

 
merci  
 
si tu trouve d'autre renseignement ou si tu as des idéé poste les ici

 
C'est ce que je dis sauf que moi j'ai remplacé x par b mais c'est pareil
 

Grosso Modo:
Version alpha: Toutes les fonctionalités planifiées sont implémentées. Trop buggé pour faire la moindre démo client.
Version béta: Toutes les fonctionalités planifiées sont implémentées. Avec des trésors d'habileté, le commercial arrive a faire des demos au clients sans planter.
Release Candidate: Idem. Bourrée de bugs connus du devellopeur, mais pas trouvés par les testeurs. Le commercial n'arrive plus a planter la version (le devellopeur, en 5 secondes, si).
Version Finale: Idem. Version sans bug client connu durant environ 24h apres sa mise en vente.
 

A+,

alpha: encore en phase de développement & test, expérimental, incomplet.
beta: fonctionnalités implantées, déboguage à faire.

Dans ma boite, c'etait version de devellopement si toute les fonctionnalités n'etaient pas implantées, et alpha a partir du moment ou elles l'etaient. Il y avait un cahier de recettes pour l'equipe de test afin de valider une version (et les suivantes) comme alpha.
 
Le numeros de version interne (incremente toutes les nuits a chaque build global par l'equipe de release) fonctionnaient comme suit:
suffixe d ==> version de dev
suffixe a ==> version alpha
suffixe b ==> version beta
pas de suffixe ==> release candidate ou definitive
 
A+,

oups j'avais pas vu dsl ;-)
  la lecture en diagonal !