Utilisation de GIT - Historique des versions

Paul le 25 août 2015 à 07:57

2015-08-25T07:57:05Z

Paul : a renommé Utilisation de CVS en Utilisation de GIT

2015-08-25T07:51:33Z

a renommé Utilisation de CVS en Utilisation de GIT

Patricia : /* Gestion des versions d'un add-on dans CVS */

2008-01-08T13:08:47Z

‎Gestion des versions d'un add-on dans CVS

Patricia : /* Ajouter un projet dans CVS (add-on, script...) */

2008-01-08T13:07:01Z

‎Ajouter un projet dans CVS (add-on, script...)

Patricia : /* Développement personnel ou expérimentation */

2008-01-08T13:06:12Z

‎Développement personnel ou expérimentation

Patricia : /* Gestion de versions incompatibles lors d'une mise à jour */

2008-01-08T13:05:22Z

‎Gestion de versions incompatibles lors d'une mise à jour

Patricia : /* Gestion des versions du noyau dans CVS */

2008-01-08T13:03:30Z

‎Gestion des versions du noyau dans CVS

Patricia : /* Commentaires de ''commit'' */

2008-01-08T13:01:58Z

‎Commentaires de ''commit''

Patricia : /* Commentaires de ''commit'' */

2008-01-08T13:01:06Z

‎Commentaires de ''commit''

Patricia : /* Commentaires de ''commit'' */

2008-01-08T13:00:15Z

‎Commentaires de ''commit''

@@ Ligne 6 : / Ligne 6 : @@
 * Faciliter la création des ''Release Notes'' à la sortie d'une nouvelle version.
-==Principe des versions et des branches du noyau dans CVS==
+==Principe des versions et des branches du noyau dans GIT==
 ===Branches stables et instables===
@@ Ligne 12 : / Ligne 12 : @@
 [[Image:ovidentia_cvs_branches.svg|thumb|300px|Principe des branches stables et instables du noyau ovidentia. Les ronds noirs sont les versions stables sur les branches PATCHS, les ronds blancs sont les versions bêta et les ronds gris les versions ''Release Candidate''.]]
-Le travail dans CVS s'éffectue sur deux types de branches : stable et instable. Les caractéristiques de ces types de branches sont les suivantes :
+Le travail dans GIT s'éffectue sur deux types de branches : stable et instable. Les caractéristiques de ces types de branches sont les suivantes :
-; Les branches stables : Elles sont nommées PATCHS-''X''-''Y''-0 dans CVS. Ces branches ne contiennent que des versions stables. Toutes les versions d'une branche stable ne contiennent que des corrections de bugs par rapport à la version initiale de la branche.
+; Les branches stables : Elles sont nommées PATCHS-''X''-''Y''-0 dans git. Ces branches ne contiennent que des versions stables. Toutes les versions d'une branche stable ne contiennent que des corrections de bugs par rapport à la version initiale de la branche.
-; La branche instable : Elle est nommée HEAD dans CVS. C'est la branche où ont lieu les nouveaux développements. Elle contient des versions bêta (dont le dernier chiffre est supérieur ou égal à 90) considérées comme instables et des versions ''release candidate'' (dont le dernier chiffre est supérieur ou égal à 100) considérées comme stables du point de vue des fonctionnalités mais non testées.
+; La branche instable : Elle est nommée master dans git. C'est la branche où ont lieu les nouveaux développements. Elle contient des versions bêta (dont le dernier chiffre est supérieur ou égal à 90) considérées comme instables et des versions ''release candidate'' (dont le dernier chiffre est supérieur ou égal à 100) considérées comme stables du point de vue des fonctionnalités mais non testées.
 Les modifications peuvent avoir lieu en parallèle sur les différentes branches. En pratique, elles n'auront lieu que sur la dernière branche stable et la branche instable : correction de bugs sur la dernière branche PATCHS-''X''-''Y''-0 et ajout de nouvelles fonctionnalités sur HEAD.
@@ Ligne 62 : / Ligne 62 : @@
 * Si nécessaire, fournit le ou les patchs au support par l'intermédiaire de l'application "Gestion des patchs" du portail extranet http://www.cantico.fr
-Il appartient au développeur de s'assurer que ses corrections ont été ''mergées'' sur la branche instable de CVS.
+Il appartient au développeur de s'assurer que ses corrections ont été ''mergées'' sur la branche instable de git.
 Il appartient à la personne qui sort la version X.(Y+1).0 de s'assurer que les branches PATCHS ont bien été ''mergées''.
@@ Ligne 91 : / Ligne 91 : @@
 Merged from PATCHS-6-2-0</pre>
-== Gestion des versions du noyau dans CVS ==
+== Gestion des versions du noyau dans GIT ==
 Avant chaque sortie de version, un tag correspondant est mis sur la branche : à la version ''X''.''Y''.''Z'' correspond le tag version-''X''-''Y''-''Z''.
@@ Ligne 144 : / Ligne 139 : @@
 Par exemple : '''SZ-SYNCHML'''
-== Ajouter un projet dans CVS (add-on, script...) ==
+== Ajouter un projet dans GIT (add-on, script...) ==
-Aucune indication sur l'environnement CVS ne doit être remplie car des informations doivent rester privées à Cantico.
-== Gestion des versions d'un add-on dans CVS ==
+== Gestion des versions d'un add-on dans GIT ==
-Tout add-on ajouté dans CVS doit avoir son entrée dans Mantis pour
+Tout add-on ajouté dans Git doit avoir son entrée dans Mantis pour
 déposer et suivre ses bugs.
@@ Ligne 168 : / Ligne 161 : @@
 </pre>
-Les versions d'un module peuvent être gérées de la forme X.YY où :
+Les versions d'un module peuvent être gérées de la forme X.Y.Z où :
 * X est la version majeure
-* YY est la version mineure
+* Y est la version mineure
-Le tag CVS aura alors la forme '''version-X-YY'''.
+Le tag git sera le numéro de version.
-A chaque sortie d'une version CVS :
+A chaque sortie d'une version git :
 * Le fichier addonini.php doit être mis à jour (incrémentation de la version)
 * Le fichier history.txt doit être mis à jour (ajout des historiques des modifications)
-* CVS doit être taggué avec un tag de la forme version-X-YY
+* git doit être taggué avec un tag contenant le numéro de version
-* Enfin le numéro de version X.YY doit être créé dans Mantis
+* Enfin le numéro de version X.Y.Z doit être créé dans Mantis

@@ Ligne 153 : / Ligne 153 : @@
 == Gestion des versions d'un add-on dans CVS ==
-Toute add-on ajouté dans CVS doit avoir son entrée dans Mantis pour
+Tout add-on ajouté dans CVS doit avoir son entrée dans Mantis pour
 déposer et suivre ses bugs.
 Un fichier history.txt dans le répertoire des fichiers php de l'add-on doit
 permettre de suivre les différentes sorties de version ainsi que les corrections apportées.
-La structure de ce fchier est la suivante:
+La structure de ce fchier est la suivante :
 <pre>
@@ Ligne 175 : / Ligne 175 : @@
-A chaque sortie d'une version CVS:
+A chaque sortie d'une version CVS :
-* Le fichier addonini.php doit être mis à jour ( incrémentation de la version )
+* Le fichier addonini.php doit être mis à jour (incrémentation de la version)
-* Le fichier history.txt doit être mis à jour ( ajout des historiques des modifications )
+* Le fichier history.txt doit être mis à jour (ajout des historiques des modifications)
 * CVS doit être taggué avec un tag de la forme version-X-YY
 * Enfin le numéro de version X.YY doit être créé dans Mantis

@@ Ligne 145 : / Ligne 145 : @@
 == Ajouter un projet dans CVS (add-on, script...) ==
-Aucune indication sur l'environnement CVS doit être remplie car des informations doivent rester privées à Cantico.
+Aucune indication sur l'environnement CVS ne doit être remplie car des informations doivent rester privées à Cantico.
 Seule remarque :

@@ Ligne 141 : / Ligne 141 : @@
 séparée.
 Le nom de la branche doit porter les initiales du développeur ayant initié la branche.
-Le nom de la branche commence par les initiales du développeur, un tiret, et un libellé.
+Le nom de la branche commence par les initiales du développeur, un tiret et un libellé.
 Par exemple : '''SZ-SYNCHML'''
 == Ajouter un projet dans CVS (add-on, script...) ==

@@ Ligne 130 : / Ligne 130 : @@
 Par principe, il ne devrait être possible de migrer que d'une version d'ovidentia vers une version sortie postérieurement.
-Par défaut, le programme de reprise autorise la mise à jour si le numéro de la nouvelle version est supérieur à la version en place. Or dans certains cas, si une branche PATCHS-''X''-''Y''-0 est prolongée après que la branche stable suivante est sortie, ou plus fréquemment lors de la sortie de versions bêta, ce système autoriserait la mise à jour d'une version récente vers une version plus ancienne : par exemple d'une 6.5.2 vers une 6.5.90 alors que la 6.5.2 est sortie après la 6.5.90. Pour cette raison il est possible, dans la configuration, d'interdire la migration d'une version du noyau vers une liste de numéros de versions spécifiée.
+Par défaut, le programme de reprise autorise la mise à jour si le numéro de la nouvelle version est supérieur à la version en place. Or dans certains cas, si une branche PATCHS-''X''-''Y''-0 est prolongée après que la branche stable suivante est sortie, ou plus fréquemment lors de la sortie de versions bêta, ce système autoriserait la mise à jour d'une version récente vers une version plus ancienne : par exemple, d'une 6.5.2 vers une 6.5.90 alors que la 6.5.2 est sortie après la 6.5.90. Pour cette raison, il est possible, dans la configuration, d'interdire la migration d'une version du noyau vers une liste de numéros de versions spécifiées.
 exemple dans le fichier version.inc :

← Version précédente	Version du 25 août 2015 à 07:51
(Aucune différence)

@@ Ligne 99 : / Ligne 99 : @@
 == Gestion des versions du noyau dans CVS ==
-Avant chaque sortie de version un tag correspondant est mis sur la branche : à la version ''X''.''Y''.''Z'' correspond le tag version-''X''-''Y''-''Z''.
+Avant chaque sortie de version, un tag correspondant est mis sur la branche : à la version ''X''.''Y''.''Z'' correspond le tag version-''X''-''Y''-''Z''.
-Si le dernier chiffre du numéro de la version est zéro une branche correspondante PATCHS-''X''-''Y''-0 est créée.
+Si le dernier chiffre du numéro de la version est zéro, une branche correspondante PATCHS-''X''-''Y''-0 est créée.
 '''Exemple :'''

@@ Ligne 77 : / Ligne 77 : @@
 Le mot-clé '''BUGM''' (et optionnellement les autres mots-clés) doit être suivi du numéro de bug dans Mantis  sous la forme '''#XXX'''.
-D'une manière générale, si les commentaires doivent apparaître dans les ''Release Notes'', il est nécessaire de créer un entrée correspondante dans Mantis (avec une sévérité correspondante) et de faire suivre le mot-clé du numéro du bug créé dans Mantis.
+D'une manière générale, si les commentaires doivent apparaître dans les ''Releases Notes'', il est nécessaire de créer un entrée correspondante dans Mantis (avec une sévérité correspondante) et de faire suivre le mot-clé du numéro du bug créé dans Mantis.
 Si la mise à jour est mineure (faute d'orthographe, correction html...), mettez '''Minor change''' afin que la personne qui lit le log comprenne que c'est bien une modification mineure.

@@ Ligne 70 : / Ligne 70 : @@
 A chaque ''commit'' dans le noyau d'ovidentia, un commentaire décrivant les changements doit être spécifié. Le commentaire doit être '''en anglais'''.
-Suivant la nature de la modification apportée au noyau, le message peut être préfixé par l'un des mot-clés suivant :
+Suivant la nature de la modification apportée au noyau, le message peut être préfixé par l'un des mots-clés suivants :
 *'''BUGM''' : il s'agit de la correction d'un bug enregistré dans Mantis,
 *'''ENHANCEMENT''' : s'il s'agit d'une amélioration,