Oui oui c'est très limité comme technique...

Mais tu peux aussi regrouper plusieurs corrections de bug sous la même lettre... et par exemple tu as aussi ça :

v 1.2e tu passes a la v1.3...
Puis tu corriges un bug : v1.3a
ainsi tu as plus de combinaison avant d'arriver a z.

Tu peux aussi faire ainsi : v1.31 etc

Mais bon je pense que GOROCO est quand même mieux

Ce message a été modifié le: 07-09-2008 07:50 PM par manip.

Je suis comme manip, le changement de version est proportionnel au changement divers effectuer.
Personnellement, je trouve logique de commencer a la version 1.0, puis de monter progressivement .

Si tu arrives a la version 1.9, tu n'es pas obligé de passé a la v2, tu fait 1.9.0 par exemple.
(si tu tien vraiment a passé des versions tous les mois, tu peux même finir a la verson 1.9.4.9, mais ça devient du n'importe quoi a mon sens, bien qu'il n'y est aucune regle officiel a ce propos).

La version 2 est censé représenter plus que de simple corrections de bugs ou petites améliorations.
Par exemple changement du design + amélioration global du game play peuvent être annonciateur de la version 2.0.

Après je pense que c'est un peu au gout de chacun. Moi je pense que la correction de bug (sauf si il y en a beaucoup ou si ils sont très gros) n'est pas vraiment un passage de version a mon sens, il faut des ajouts plus que des corrections de choses déjà censé marcher...

Ce message a été modifié le: 07-10-2008 09:23 AM par keke.

J'utilise simplement les révisions de Subversion, le fichier de configuration est automatiquement taggé.

Pour ma part, cela me servira plus d'outils de référencement, car chaque nouvelle révision entraine une nouvelle description des modifications effectuées.
Donc, plus de pages.

Avec le GOROCO, tu réponds à pratiquement tous les problèmes que tu viens de mentionner. En plus, c'est simple d'usage et de compréhension. Tu peux l'appliquer à chaque projet quel qu'en soit la taille (A FT, là où j'ai découverts ce principe, il était utilisé par des projets de plusieurs millions d'euros).

Ainsi, si tu arrive à la version G1R9 commen mentionné, ben tu passes à la G1R10 si tu juge que ce n'est pas une "grosse évolution".
Si tu fais des corrections, elles n'apparaissent pas à l'utilisateur car tu passes de la version G1R10C1 à la G1R10C2 ... et l'utilisateur n'a pas conscience de la version Corrective. (je rappelle : G = générale, R = release = version opérationnelle, C = corrective.)

Tu passe de G1 à G2 lors de grosse avancée dans le jeu (en ton sens, cela peut être du gameplay, une nouvelle ergonomie etc ..)
Tu passes de R1 à R2 pour les petites avancées du jeu
et tu passes de C1 à C2 avec les corrections de bugs.

Voilou !
Kéké.

Peux-tu détailler s'il te plaît ? Ça m'intéresse.


Sephi-Chan

J'utilise la propriété Autoprops de Tortoise SVN, couplé à la propriété set:keywords, elle me permet de retourner, tout un tas d'informations taggés directement à l'exportation dans les fichiers demandés.

Au final, je tag mon fichier de configuration pour récupérer de façon automatique la dernière révision et la dernière date de modification.

Outre Tortoise, SVN en ligne de commande doit pouvoir être configuré de la même manière.

Effectivement, je n'ai pas encore eu l'occasion de bien fouiller SVN en ligne de commande. :s


Sephi-Chan

http://svnbook.red-bean.com/en/1.1/ch07s02.html

Elles sont expliquées ici.

Je l'ai configuré comme ceci pour ma part :