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
Sur la base de quoi le versionning
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.
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.
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.
- Etant donné que je suis "encore" sur windows je vais tenter de trouver une version tournant dessus. Zend studio semblerais gérer Subversion.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.
- 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...).
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.
Installe Tortoisesvn sur ton windows.
De plus il te permet de monter un repository svn en localA 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.
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°
Pourquoi c'est une mauvaise idée?Installe Tortoisesvn sur ton windows.
De plus il te permet de monter un repository svn en local
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.
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°
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.
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.
2-0
Echec total. A croire que je suis aidé par le PSG (non là je suis dure
Premier but de SubVersion
Impossible d'installer SubVersion sur windows malgré le tuto présent sur développez. Impossible de ce connecter. L'outil client avec la tortue ne s'installe même pas.
Second but dans la seconde Mi-temps par DotProjet
Il s'installe mais pas avec la version 5 de Mysql. Des dire du responsable, il a du dribler un bon coup pour que ça puisse fonctionner.
Allez! lache l'affaire.
Est-ce que tu travailles sur une seule machine, comprendre: est ce que tes sources sont sur la meme machine que le dépot svn ?
Oui.
j'ai bien placer svn://localhost/monprojet un truc comme ça.
Il me propose pas de me loger. J'ai suivi le tuto comme un mouton pourtant
Si tu travailles uniquement en local tu n'as besoin que de TortoiseSVN.
Je t'en dis plus tout à l'heure.
Haa ça devient intéressant.
Il se pourrait que j'ai pas fait attention mais je pense peut être avoir prit une mauvaise version la 64bit.
Voili voilou comment je procède :
1. Installation de TortoiseSVN
Facile.
2. Création d'un dépot (repository) subversion
Je mets mon dépot sur une partition autre que C:
Je crée un dossier d:\svnroot
Je vais dedans avec l'explorer et je fais bouton droit >
Je laisse en fsfs
Le dépot est créé
3. Import des sources dans subversion
Par exemple mon installation de Wamp est dans c:\wamp
Je vais dans c:\wamp\www
Je crée un dossier temporaire c:\wamp\www\tmp et je copie dedans tous les dossiers qui doivent être sous controle de version :
Ensuite je fais bouton droit sur le répertoire tmp :
Puis je renseigne l'url qui va bien : file:///d:/svnroot/
Les sources sont sous controle de version
Je peux supprimer mon répertoire temporaire
4. Je fais un checkout
N'importe où sur mon filesystem, je fais un checkout du projet que je veux.
Si je veux travailler dans www, il faut supprimer les anciennes sources (faire une copie au préalable). Donc je supprime test_parcours dans mon exemple, puis dans l'explorer, je fais bouton droit > checkout :
Et voilà, on peut travailler maintenant, la petite coche verte nous indique qu'on est up-to-date
Ceci bien entendu pour une utilisation purement locale !
C'est d'la bombe de balle couzin. Je teste ça des ce soir.
C'est terrible ça fonctionneje vais pouvoir bien m'amuser avec
.
Je pense que c'est un petit tuto à placer dans les contributions
Merci!
J'ai un petit update à faire à propos de Subversion.
En effet j'étais pas très satisfait de la partie 3. Import des sources dans subversion
Ce truc du répertoire temporaire c'est vraiment trop lourd à mon gout.
Voici une autre méthode beaucoup plus simple :
Imaginons que j'ai un projet 'ProjectOfTheYear' :
Il suffit de faire bouton droit sur ce dossier, de faire un import. L'url de dépot est file:///d:/subversion/ProjectOfTheYear
Code : Sélectionner tout - Visualiser dans une fenêtre à part c:\wamp\www\ProjectOfTheYear\
C'est tout, je vous avait dit que c'était plus simple
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