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) :

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 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).