IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Astuce : Utiliser un contrôleur de version (SVN) depuis l'explorateur de fichiers (Windows)

Le , par berceker united
44 commentaires

0PARTAGES

0  0 
Bonjour,
Voila, voulant établire un certain suivi sur mes classes plus les methodes j'insere des numéro de version pour chacun d'eux. Ma question est de savoir sur quel critère on détermine une évolution de version. Quel est le format j'en vois plusieurs :
1.0.0.0 - 1.0 - 1.2.3. ça commence a partir de combien ? un ou zéro ?
Alpha => Beta => Release. pour ça j'ai compris.

Je developpe seul mais je pense que j'installerais subversion mais est-ce utile ?

Merci.

Une erreur dans cette actualité ? Signalez-nous-la !

44 commentaires
Commenter Signaler un problème
Mr N.
Avatar de Mr N.
Expert éminent https://www.developpez.com
Le 17/10/2006 à 13:32
Oui utilise subversion, même quand t'es tout seul. En tout cas c'est ce que je fais. Pratique pour savoir pourquoi j'ai fait telle ou telle modif, faire des diff entre différentes versions d'un script, ... Pratique aussi pour le prototypage (je suis à une version stable, je tente un truc en modifiant des fichiers, ça marche pas => svn revert et c'est marre). Bref, trop cool

Ensuite concernant le versionnage (1.0.3, ...) je le déconseille sur des fichiers. Réserve le plutot à des application ou composants entiers et indépendants.

J'applique personnellement la politique suivante :
X.Y.Z =>
X == évolution majeure du produit.
Y == évolution mineure du produit.
Z == correction de bugs

Exemple : j'en suis à la 2.4.6
La prochaine version sera :
- 2.4.7 si je corrige un bug
- 2.5.0 si j'ajoute une ou plusieurs petites fonctionnalités qui ne modifie pas l'architecture
- 3.0.0 si je touche en profondeur l'appli (passage à PHP5, ajout d'une grosse fonctionnalité, ...)

A noter que plus tu as des versions, plus tu dois les maintenir.
0  0 
is_null
Avatar de is_null
Inscrit https://www.developpez.com
Le 17/10/2006 à 13:39
Si on estime une version à plus de 100 bugs, c'est une version alpha.
A moins de 100 bugs, c'est une beta.
Si la version du programme est potentiellement stable, on l'appelle Release Candidate.
0  0 
berceker united
Avatar de berceker united
Expert éminent https://www.developpez.com
Le 17/10/2006 à 13:54
Citation Envoyé par Mr N.
Oui utilise subversion, même quand t'es tout seul. En tout cas c'est ce que je fais. Pratique pour savoir pourquoi j'ai fait telle ou telle modif, faire des diff entre différentes versions d'un script, ... Pratique aussi pour le prototypage (je suis à une version stable, je tente un truc en modifiant des fichiers, ça marche pas => svn revert et c'est marre). Bref, trop cool

Ensuite concernant le versionnage (1.0.3, ...) je le déconseille sur des fichiers. Réserve le plutot à des application ou composants entiers et indépendants.

J'applique personnellement la politique suivante :
X.Y.Z =>
X == évolution majeure du produit.
Y == évolution mineure du produit.
Z == correction de bugs

Exemple : j'en suis à la 2.4.6
La prochaine version sera :
- 2.4.7 si je corrige un bug
- 2.5.0 si j'ajoute une ou plusieurs petites fonctionnalités qui ne modifie pas l'architecture
- 3.0.0 si je touche en profondeur l'appli (passage à PHP5, ajout d'une grosse fonctionnalité, ...)

A noter que plus tu as des versions, plus tu dois les maintenir.
- Etant donné que je suis "encore" sur windows je vais tenter de trouver une version tournant dessus. Zend studio semblerais gérer Subversion.
- Merci c'est ce que je voulais savor. Je pense que je prendrais ta façon de déterminer les évolutions de numéro. Je ne voulais pas le faire sur les fichier mais sur le classe et les methode de cette même classe. Ceci me permet d'avoir une précision étant donnée que je developpe entièrement en objet ceci afin que je ne rate rien. Surtout que je pose des commentaire à la norma java (phpdoc...).

Citation Envoyé par is_null
Si on estime une version à plus de 100 bugs, c'est une version alpha.
A moins de 100 bugs, c'est une beta.
Si la version du programme est potentiellement stable, on l'appelle Release Candidate.
Merci j'y penserais mais dans les testes unitaire de chaque classe dans la mesure du possible mais cela me fait penser qu'il faut qu'il faut je mette noir sur blanc les test à faire et les resultats attendu afin de déterminer si c'est concidérer comme stable ou non.

Harf!.. tenter de monter un projet propre ça nécessite beaucoup de chose.
Au passage, je pense que je vais utiliser un outil de gestion de projet tel que DotProject qui m'a l'air pas trop mal quoi que un peut "usine à gaz"

Merci à vous mais c'est la bienvenu s'il y a d'autre contribution.
0  0 
Mr N.
Avatar de Mr N.
Expert éminent https://www.developpez.com
Le 17/10/2006 à 14:06
Installe Tortoisesvn sur ton windows.
De plus il te permet de monter un repository svn en local A moins bien sur que tu héberges proprement tes sources sur un sourceofrge/trac ou similaire.

Par contre je persiste à penser que c'est une mauvaise idée de tagger des fichiers/classes individuellement. M'enfin, c'est personnel tout ça, tu verras bien par toi même à l'usage
Sinon n'oublie pas que tu peux mettre des $Id$ (et autres mot clés) dans tes commentaires. Ainsi à chaque revision ils seront substitués et donc tu sauras quand et qui a modifié le fichier et quelle est sa révision.
0  0 
kankrelune
Avatar de kankrelune
Membre éclairé https://www.developpez.com
Le 17/10/2006 à 14:16
Citation Envoyé par Mr N.

J'applique personnellement la politique suivante :
X.Y.Z =>
X == évolution majeure du produit.
Y == évolution mineure du produit.
Z == correction de bugs
Je fonctionne de la même façon... c'est la manière normale de faire... par contre pour les alpha,beta,etc je ne fonctionne pas pareil... pour moi la version d'un script qui a plus de 100 bugs potentiel c'est même pas encore une alpha... .. .

@ tchaOo°
0  0 
berceker united
Avatar de berceker united
Expert éminent https://www.developpez.com
Le 17/10/2006 à 14:18
Citation Envoyé par Mr N.
Installe Tortoisesvn sur ton windows.
De plus il te permet de monter un repository svn en local A moins bien sur que tu héberges proprement tes sources sur un sourceofrge/trac ou similaire.

Par contre je persiste à penser que c'est une mauvaise idée de tagger des fichiers/classes individuellement. M'enfin, c'est personnel tout ça, tu verras bien par toi même à l'usage
Sinon n'oublie pas que tu peux mettre des $Id$ (et autres mot clés) dans tes commentaires. Ainsi à chaque revision ils seront substitués et donc tu sauras quand et qui a modifié le fichier et quelle est sa révision.
Pourquoi c'est une mauvaise idée?
La version principale sera sur celui du fichier donc la classe vu qu'il y a un fichier par classe.
0  0 
kankrelune
Avatar de kankrelune
Membre éclairé https://www.developpez.com
Le 17/10/2006 à 14:33
Citation Envoyé par berceker united
Pourquoi c'est une mauvaise idée?
La version principale sera sur celui du fichier donc la classe vu qu'il y a un fichier par classe.
Je dirais comme Mr N... à partir du moment ou le fichier n'est pas indépendant il n'est pas utile de lui donner un numérot de version vu qu'il dépend de(s) script parents et donc hérite de leur numérot de version... par contre si ton script/classe est un script indépendant, genre plugin, là tu peux lui donner un numérot de version perso... .. .

C'est plus logique, ça donne moins de taf et allège le suivi des versions... .. .

@ tchaOo°
0  0 
berceker united
Avatar de berceker united
Expert éminent https://www.developpez.com
Le 17/10/2006 à 15:36
Citation Envoyé par kankrelune
Je dirais comme Mr N... à partir du moment ou le fichier n'est pas indépendant il n'est pas utile de lui donner un numérot de version vu qu'il dépend de(s) script parents et donc hérite de leur numérot de version... par contre si ton script/classe est un script indépendant, genre plugin, là tu peux lui donner un numérot de version perso... .. .

C'est plus logique, ça donne moins de taf et allège le suivi des versions... .. .

@ tchaOo°
Ok je comprend. Donc en gros je peux le faire à deux niveaux. Dans le fichier / class/ methode Juste pour moi pour mon suivi d'évolution personnel mais pour subversion je gère les versions au niveau des modules qui est ensemble de scripts.
0  0 
Mr N.
Avatar de Mr N.
Expert éminent https://www.developpez.com
Le 17/10/2006 à 15:47
Attention à ne pas confondre "version" et "revision".
La "revision" correspond à un commit. Un numéro de révision est attribué automatiquement à tout le repository (à la différence de cvs où c'est fichier par fichier).
Quand à la version, ça correspond à la branche sous cvs, attribué manuellement par le developpeur/chef => X.Y.Z
0  0 
berceker united
Avatar de berceker united
Expert éminent https://www.developpez.com
Le 17/10/2006 à 17:01
Citation Envoyé par Mr N.
Attention à ne pas confondre "version" et "revision".
La "revision" correspond à un commit. Un numéro de révision est attribué automatiquement à tout le repository (à la différence de cvs où c'est fichier par fichier).
Quand à la version, ça correspond à la branche sous cvs, attribué manuellement par le developpeur/chef => X.Y.Z
Ha effectivement c'est pas la même chose et il ne faudrait pas que je me base dessus en parlant de la révision. La version je voudrais la poser moi même.

Je pense qu'en utilisant subservion j'y verrais plus claire car là pour l'instant cela me parait peut être un peut trop abstrait pour que je puisse décider quoi faire.
0  0 
Commenter Signaler un problème