Releases et versions : lire 202701 et 8.20.0
Trois numéros circulent autour d'un schéma Telebib2 et ils ne disent pas la même chose : la release dans le nom du fichier, la version du message dans le message lui-même et la version du registre dans sa table de compatibilité. Les confondre conduit à des raisonnements faux sur la compatibilité. Voici comment les lire.
La release : une période, pas un état du dépôt
Une release regroupe les schémas valables pour une période donnée du cycle annuel. Elle s'écrit AAAANN (202701 désigne la release du 1er janvier 2027) et figure dans le nom de chaque fichier.
Le point qui surprend : le registre n'est pas « en release 202701 ». Ses messages relèvent de neuf releases différentes, toutes en service en même temps. Un message qui n'a pas changé depuis 2006 y côtoie un message refondu pour 2027 et les deux sont pleinement valides.
C'est la conséquence directe de l'immuabilité : rien n'est retiré parce qu'une nouvelle release arrive. Un message n'obtient un nouveau fichier que s'il a réellement changé.
Le numéro de séquence (le 01 de 202701) laisse la place à des releases intermédiaires dans l'année, réservées aux corrections qui ne peuvent pas attendre. Les améliorations et les nouveaux champs facultatifs attendent la release annuelle suivante.
La release est dans le nom
M0151.202701.json refondu pour 2027
M0140.201510.json inchangé depuis 2015
M0421.200601.json inchangé depuis 2006
La version du message : relative, toujours
Chaque message porte son propre compteur de version, transmis dans le message sous le nom exchangeUnitBusinessContentDescriptionVersion, le X944 d'EDIFACT.
Ce compteur est relatif à chaque message. La version 3 de M0151 et la version 3 de M0103 n'ont aucun rapport : ce sont deux compteurs indépendants qui ont simplement atteint le même chiffre. C'est pourquoi le couple code + version est le seul identifiant fiable d'un message et pourquoi le routeur discrimine toujours sur les deux.
Ce compteur ne dit rien de la date : la version 23 d'un message très remanié et la version 1 d'un message stable peuvent parfaitement appartenir à la même release.
Dans le message
{
"exchangeUnitBusinessContentDescription": "M0151",
"exchangeUnitBusinessContentDescriptionVersion": 3
}
La version du registre : d'où vient le contenu
Le registre porte sa propre version, dans compatibility.json. Elle s'aligne sur la version de la base Telebib2 dont les schémas sont dérivés, suivie d'un numéro de correctif propre au JSON.
Dans 8.20.0, le 8.20 est la version de la base (elle change quand une nouvelle version de la base est publiée) et le .0 compte les corrections apportées côté JSON entre deux versions de base. Il repart à zéro à chaque fois. Le champ dbVersion répète la version de base seule, pour éviter d'avoir à découper le numéro.
Ce n'est pas du versionnage sémantique et c'est le piège à éviter. Un incrément mineur suit la cadence de la base et peut parfaitement être cassant : une version de base retire régulièrement des valeurs de liste, ce qui invalide des messages jusque-là valides. Se fier au numéro pour présumer la compatibilité serait une erreur. C'est la liste des changements qui fait foi.
L'en-tête du registre
{
"registryVersion": "8.20.0",
"dbVersion": "8.20",
"releaseTarget": "202701",
"status": "pre-release"
}
Deux axes qui ne se croisent pas
Version et release sont deux axes indépendants et c'est la clé pour ne pas s'y perdre.
Une même version du registre peut porter des changements pour plusieurs releases à la fois. Par exemple, corriger un message de 2026 et en préparer un de 2027 dans la même livraison. Inversement, une release s'étale sur de nombreuses versions du registre avant d'être complète.
L'axe release vit dans le nommage des fichiers, dans les dates de la table de compatibilité et dans le routage. L'axe version vit dans l'en-tête du registre. Jamais dans des branches, jamais dans des étiquettes de dépôt.
Une conséquence pratique : ne demandez pas « quelle release utilisez-vous ? » car la question n'a pas de réponse. Demandez quelle version de registre et quelles versions de messages vous échangez.
Le passage en production
Le registre porte aujourd'hui le statut pre-release. Au 1er janvier 2027, il passera à published. C'est le seul changement : la numérotation ne bascule pas, les noms de fichiers ne changent pas, les identifiants restent les mêmes.
Le champ releaseTarget indique la release visée par les travaux en cours. C'est une information sur l'activité du groupe, pas une propriété du registre. Quand 202801 sera en préparation, il changera, sans que 202701 disparaisse pour autant.
