meta données pour cette page
  •  

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision		Révision précédente
certif:questionnaire:procedure:develop:gestionversion [2026/08/11 14:04] – nicolascertif:questionnaire:procedure:develop:gestionversion [2026/08/11 15:13] (Version actuelle) – supprimée nicolas
Ligne 1: Ligne 1:
-====== Procédure de Gestion des Versions ====== 
- 
-## Informations qualité 
- 
-**Historique des modifications :** 
-  * 2026-08-11 : Nicolas Marchand — fusion des procédures #06 (gestion de version) et #30 (gestion des tags Git, page ``gestionsvn``, désormais obsolète — voir lien en bas de page) en un seul document. Nouveau mécanisme de signalement des versions beta (4ᵉ chiffre porteur de la version visée, remplace le signal ``Y=99``). Alignement du client lourd et des serveurs sur cette même règle (auparavant spécifique à LoGeAs Web). 
-  * 20/11/2025 : Nicolas Marchand, Guillaume Natali — dernière version de la procédure #06 avant fusion 
-  * 3 décembre 2015 : Guillaume Natali — création de la procédure #30 
- 
-**Numéro de procédure :** à attribuer ultérieurement (fusion récente, en cours de stabilisation). 
- 
-**Approbations :** Gérant (validation des modifications), Équipe DEV (approbation) 
- 
-## Objectif et périmètre 
- 
-Cette procédure définit le système de versionnage utilisé pour l'ensemble des composants LoGeAs — **LoGeAs Web**, qui fait référence, ainsi que le **client lourd** et les **serveurs** (PGI, LoGeAs, Nono) — et la façon dont chaque version est enregistrée dans son dépôt Git avec identification unique et authenticité garanties. 
- 
-Chaque composant conserve son propre numéro de version et son propre rythme de publication (ils ne sont pas synchronisés entre eux), mais tous suivent désormais **la même règle de numérotation**. Une matrice de compatibilité (fin de document) recense les versions connues de chaque composant. 
- 
-## Système de Numérotation 
- 
-Le numéro de version comporte 3 chiffres pour une version publiée, et 4 chiffres pendant sa phase de test beta : 
- 
-  * **X (Majeur)** — numéro marketing/stratégique. Reflète des évolutions substantielles ou des migrations technologiques (ex. changement de base de données). 
-  * **Y (Mineur)** — nouvelles fonctionnalités, modifications de structure de données, changement de réglementation ou nouvelle certification. 
-  * **Z (Release)** — change à **chaque publication du logiciel** (obligatoire). Ne réutilise jamais un numéro déjà publié. 
-  * **W (Build, uniquement pendant une phase beta)** — numéro d'itération de la beta en cours de test. 
- 
-## Règle fondamentale 
- 
-Une fois qu'une version **X.Y.Z** est publiée, son contenu ne doit **jamais** être modifié. Toute modification, même mineure, exige une nouvelle version. 
- 
-## Signalement d'une version beta (X.Y.Z.W) 
- 
-Une version en cours de test beta porte directement le numéro **X.Y.Z que cette beta vise à publier**, suivi d'un 4ᵉ chiffre **W** qui numérote les itérations successives de cette beta (1, 2, 3…), remis à 1 à chaque nouveau cycle. 
- 
-**Exemple concret :** 
-  * Dernière version publiée : ``11.0.25`` 
-  * Un correctif est en préparation, sans nouvelle fonctionnalité → il vise ``11.0.26``. Sa 1ʳᵉ beta est numérotée ``11.0.26.1``, un correctif suite à retour de test donne ``11.0.26.2``, etc. 
-  * Une fois validée, la beta ``11.0.26.2`` devient la release ``11.0.26`` (le 4ᵉ chiffre est retiré, le X.Y.Z ne change pas). 
-  * Une évolution plus importante (nouvelles fonctionnalités) viserait ``11.1.0`` au lieu de ``11.0.26`` — ses betas seraient ``11.1.0.1``, ``11.1.0.2``, etc. 
- 
-**Pourquoi ce mécanisme plutôt que l'ancien signal ``Y=99``** (utilisé auparavant, y compris dans le code du client lourd) : avec un flag générique, deux cycles beta consécutifs qui ne changent pas le mineur — le cas le plus fréquent — produisent le même numéro de beta, sans moyen de savoir à quelle version future chacun correspond. En faisant porter directement le numéro visé, l'ambiguïté disparaît et la progression reste strictement croissante, sans trou ni collision possible. 
- 
-## Critères de Changement de Version 
- 
-**Majeur (X)** : évolutions substantielles ou migrations technologiques (ex. changement de base de données). 
- 
-**Mineur (Y)** : nouvelles fonctionnalités, modifications de structure de données (ajout de champs), changements de réglementation pris en compte, ou nouvelle certification. 
- 
-**Release (Z)** : à chaque publication du logiciel (publication obligatoire) — correctifs, corrections de bugs, ajustements sans changement fonctionnel structurant. 
- 
-**Build (W)** : uniquement pendant une phase beta, itération de test au sein d'un même cycle. N'apparaît jamais sur une version publiée. 
- 
-## Actions Requises par Type de Version 
- 
-### Version Majeure 
-Avant développement : Séparation de la documentation utilisateur. 
- 
-Avant livraison : Validation complète des tests ProjeQtOr, mise à jour de documentation technique/utilisateur, création d'actualités web, taguage Git (voir ci-dessous), archivage des binaires, modification des URLs de mise à jour, mise à jour EPUdF REGALE. 
- 
-Après livraison : Notification utilisateurs, dépôt auprès EPUdF et coffre numérique. 
- 
-### Version Mineure 
-Avant livraison : Validation des tests, évolution documentation technique/utilisateur, mise à jour actualités web, taguage Git, archivage binaires, mise à jour EPUdF REGALE. 
- 
-Après livraison : Notification utilisateurs, dépôt coffre numérique, extension certification logiciel. 
- 
-### Version Release 
-Avant livraison : Validation des tests pertinents, mise à jour documentation technique, actualités web, taguage Git, archivage binaires, mise à jour EPUdF REGALE. 
- 
-Après livraison : Dépôt codes/binaires en coffre numérique. 
- 
----- 
- 
-## Gestion des tags Git 
- 
-### Format des tags 
- 
-  * Beta : ``X.Y.Z.W_beta`` (ex. ``11.0.26.1_beta``) 
-  * Release : ``X.Y.Z_release`` (ex. ``11.0.26_release``) 
- 
-Ce format s'applique au dépôt LoGeAs Web (``logeas-web``). Les dépôts du client lourd et des serveurs (``logeas-web`` historique, groupe Delphi) utilisent une convention de tag distincte, héritée de leur propre historique (ex. ``NonoVersion11.0.1.0``, ``LoGeAsVersion11.0.2.3Pré-release``) — non harmonisée avec le format ci-dessus pour l'instant. 
- 
-### Étapes d'exécution — LoGeAs Web 
- 
-Outillées via les commandes ``/release-beta`` et ``/release-client`` (assistant Claude Code, dépôt logeas-web) : 
- 
-1. **Vérification de branche** : la branche de version est propre et à jour avec le dépôt distant 
-2. **Génération du build** : compilation, incrémentation automatique du numéro (4ᵉ chiffre pour une beta, 3ᵉ chiffre pour une release) 
-3. **Commit dédié** : le changement de numéro de version est commité séparément du contenu fonctionnel 
-4. **Étiquetage** : tag Git annoté créé sur ce commit 
-5. **Publication** : push du commit et du tag vers le dépôt distant 
-6. **Relevé d'empreinte** : le hash de commit court est embarqué automatiquement dans ``src/assets/version.ts``, consultable directement dans le logiciel livré 
-7. **Archivage** : conservation de la référence du tag dans le suivi de version (cartographie fonctionnelle) 
- 
-### Cas d'un tag posé manuellement 
- 
-Respecter impérativement le format défini ci-dessus et ne jamais réutiliser un numéro X.Y.Z déjà présent dans un tag ``_release`` existant. 
- 
----- 
- 
-## Numérotation des autres composants (client lourd, serveurs) 
- 
-Le client lourd (Delphi, dépôt ``logeas-web`` du groupe historique) et les serveurs (PGI, LoGeAs, Nono) suivent désormais **la même règle de numérotation** que LoGeAs Web (voir ci-dessus), chacun sur sa propre ligne de version indépendante. 
- 
-**Alignement technique effectué :** le code partagé ``CommunGlobaux/CommonLoGeAs.pas`` contenait un mécanisme spécifique au signal ``Y=99`` (``if v[1]>=99 then inc(v[0])``, dans ``GetPathData`` et ``InitVersion``), utilisé pour corriger le calcul du dossier de données et du libellé de version pendant une beta de version majeure. Cette correction devenant obsolète (plus aucune version n'est censée utiliser ``Y=99``), les 2 occurrences ont été retirées. *(Changement réalisé le 2026-08-11, non encore commité au moment de la rédaction — à valider par compilation/test avant intégration.)* 
- 
-**Point de vigilance :** un mécanisme de récupération active de la version de LoGeAs Web depuis le client lourd existe déjà en code (``TCommonLoGeAs.GetVersion_LogeasWeb``, appel prévu vers le serveur Nono, ``getVersionGlobale``), mais son corps est actuellement commenté (désactivé). Il pourrait être réactivé plus tard pour passer d'une matrice de compatibilité déclarative à un contrôle actif à la connexion — non fait à ce stade. 
- 
-## Matrice de compatibilité 
- 
-Versions connues au 2026-08-11 (relevées dans les fichiers projet ``.dproj`` du dépôt Delphi) : 
- 
-^ Composant ^ Version connue ^ Remarque ^ 
-| LoGeAs Web (référence) | 11.0.25 | | 
-| Client lourd (LOGEAS.exe) | 11.0.3.1 | | 
-| Serveur LoGeAs (LoGeAsWebServeur) | 11.0.2.97 | | 
-| Serveur PGI | 9.4.6 | ligne de version indépendante, pas alignée sur le 11.x des autres composants | 
-| Serveur Nono | non renseigné dans le ``.dproj`` (valeurs par défaut) | dernier tag Git connu : ``NonoVersion11.0.1.0`` — écart à corriger | 
- 
-Cette matrice est mise à jour manuellement à chaque publication notable. Pas de vérification automatique pour l'instant (voir « point de vigilance » ci-dessus pour une évolution possible). 
- 
----- 
- 
-## Documents fusionnés dans cette page 
- 
-Cette procédure remplace et fusionne : 
-  * L'ancienne procédure #06 « Gestion des Versions de LoGeAs » 
-  * La procédure #30 « Versionning des codes sources », page [[certif:procedure:develop:gestionsvn|désormais obsolète]] 
- 
-## Suivi Document 
-Dernière modification : 2026-08-11. Auteurs : Nicolas Marchand, Guillaume Natali. Validateurs : Gérant (modifications), Équipe dev et assistance (approbation).