Versions, compatibilité et correctifs DYNORS¶
Publication vérifiée — 5 novembre 2026 : Paiement 2.0.0, image Boot 4.1.2 / Java 21 AMD64 et ARM64. Publication applicative, sans changement de BOM ni déploiement. Voir les preuves, migrations et réserves. Les indications historiques ci-dessous doivent être lues avec ce complément.
Référence vérifiée le 15 octobre 2026, depuis les registries Maven Core (projet 75907047) et Extensions (76017499), leurs POM et les reçus de release. Une version disponible n'est ni une adoption applicative ni un GO production.
Guide DB actuel · Historique documentaire avant ce contrôle.
1. Choisir selon le niveau réel de son application¶
| Application | Ligne de départ | Ce qui reste à prouver |
|---|---|---|
| Boot 3 | Modules 1.x compatibles avec son graphe ; Core BOM 1.0.14 reste sur l'ancienne ligne | Résolution effective, correctifs réellement embarqués et tests produit ; ne pas adopter DB/InterApp/PDF/Notify 2.x Boot 4 par simple bump |
| Boot 4 | Modules Boot 4 publiés ci-dessous, sélection explicite tant que les nouveaux BOM ne sont pas publiés | Graphe complet, API Spring 7, bootstrap, sécurité, données et image finale |
| PostgreSQL 17 | Cible immédiate de qualification et d'adoption progressive | DB 2.1, puis migration et preuves propres à chaque application |
| MySQL | Chantier différé par décision du propriétaire | Aucun GO MySQL déduit de DB 2.1 ; version cible et qualification à traiter ultérieurement |
La maintenance des anciennes lignes et la migration avancent indépendamment. Un correctif compatible peut faire l'objet d'une nouvelle release de maintenance, après qualification et autorisation ; aucune ancienne release n'est réécrite. Il n'y a ni migration forcée, ni promesse de backport automatique ou illimité.
2. Modules réellement disponibles¶
La colonne « socle » décrit le POM et/ou le reçu indiqué : elle ne certifie pas toutes les versions mineures de Boot 3 ou Boot 4. Java 17 est le minimum des releases récentes qualifiées ici ; Java 17 et 21 sont deux preuves distinctes.
Core¶
| Module | Stable observée | Socle / état vérifié | Attention |
|---|---|---|---|
| dynors-commons | 1.0.10 | POM Boot 3.2.0 ; primitives D0, reçu disponible | Ce numéro ne signifie pas « Commons natif Boot 4 » ; contrôler les transitives du consommateur |
| dynors-security | 1.0.10 | POM Boot 3.2.0 ; dépend de DB 1.0.8 | Pas de GO Spring 7 déduit de sa publication |
| dynors-db | 1.0.14 | Ancienne ligne Boot 3 ; correctifs isolation/quotas | Catalogue complet non créé par cette release |
| dynors-db | 2.0.0 | Boot 4.1.1 / Spring 7.0.9 ; PG 15/16 qualifiés | Ne livre pas le bootstrap complet du catalogue |
| dynors-db | 2.1.0 | Publiée, package 72581746 ; fichiers registry identiques au publisher | Catalogue SQL/Liquibase, fixtures et PG 17 ; adoption explicite après tests produit |
| dynors-events | 2.0.0 | POM Boot 3.2.0 ; contrat de confirmation broker publié | Events 2 ne signifie pas Boot 4 ; candidat Boot 4 distinct, non publié |
| dynors-interapp-client | 2.0.0 | POM Boot 4.1.1 | Adoption volontaire ; vérifier aussi le graphe Commons et les contrats de transport |
| dynors-web-errors | 1.0.9 | POM Boot 3.2.0 | Candidat Boot 4 distinct, non publié |
Extensions : SDK modernes et ligne antérieure¶
| Module | Stable observée | Socle / état vérifié | Adoption |
|---|---|---|---|
| dynors-pdf | 2.0.0 | Boot 4.1.1 / Spring 7.0.9 ; JDK 17/21 | PDFBox 3, contrat de templates et limites à respecter |
| dynors-notify | 2.0.0 | Boot 4.1.1 / Spring 7.0.9 ; JDK 17/21 | Reçu détaillé, provider/configuration et réconciliation à qualifier |
| dynors-media (SDK) | 1.0.4 | POM Boot 3.5.16 | Ne pas confondre le SDK avec le service Media déployable |
| dynors-logging | 1.0.5 | POM Boot 3.2.0 | Compatibilité Boot 4 non qualifiée par ce lot |
Anciennes stables PDF 1.0.5 et Notify 1.0.7 : toujours disponibles et immuables ; ne pas leur attribuer les corrections/API de 2.0.0.
Autres dernières stables observées au registry : api-client 1.0.3, billing 1.0.5, webhooks 1.0.4, invoicing-core 1.0.5, fiscal-client 1.0.1, entitlements-client 1.0.3, auth-ldap 1.0.3 et licensing 1.0.2. Leur présence est vérifiée ; leur compatibilité Boot 4 n'est pas qualifiée par cet inventaire. Ce sont des lots à examiner, pas une autorisation de les mélanger au futur BOM Boot 4.
3. BOM : contenu exact, pas version supposée¶
Core BOM 1.0.14 — publié, ligne antérieure¶
| Contrainte | Version inscrite dans son POM |
|---|---|
| dynors-commons | 1.0.8 |
| dynors-security | 1.0.10 |
| dynors-db | 1.0.12 |
| dynors-events | 1.0.9 |
| dynors-interapp-client | 1.0.9 |
| dynors-web-errors | 1.0.8 |
Ce BOM n'embarque ni DB 1.0.14, ni DB 2.x, ni Events 2.0.0, ni InterApp 2.0.0. Un correctif publié séparément n'apparaît pas magiquement dans une ancienne composition. Les BOM 1.0.13 et antérieurs restent des compositions historiques, pas des synonymes de « toutes les dernières versions ».
Extensions BOM 1.0.4 — anomalie publiée, ne pas recommander tel quel¶
Le POM distant référence notamment :
| Contrainte | Valeur publiée |
|---|---|
| dynors-notify / dynors-pdf | 1.0.3 / 1.0.3 |
| dynors-logging | 1.0.4 |
| dynors-api-client | 1.0.4-SNAPSHOT # gitleaks |
| dynors-webhooks / dynors-billing / dynors-media | 1.0.3 / 1.0.3 / 1.0.3 |
| dynors-fiscal-client / dynors-entitlements-client | 1.0.0 / 1.0.0 |
| dynors-auth-ldap / invoicing-core | 1.0.3 / 1.0.3 |
| dynors-core-bom importé | 1.0.7 |
La valeur api-client est une contrainte Maven invalide, pas un commentaire XML. Elle contrevient aussi à la règle interdisant les dépendances DYNORS SNAPSHOT. Un module non utilisé peut masquer ce défaut ; un build partiel vert ne valide donc pas le BOM entier. Ne pas réécrire 1.0.4 : préparer une nouvelle composition de maintenance cohérente si nécessaire. Les versions individuelles stables restent sélectionnables et qualifiables sans adopter ce BOM.
Futurs BOM 2.x — ligne Boot 4, non publiés au contrôle du jour¶
Décision de trajectoire : les nouveaux BOM 2.x correspondent à la ligne Boot 4. Le numéro des modules reste indépendant : par exemple Events 2.0.0 reste Boot 3, tandis que son candidat Boot 4 est 3.0.0-SNAPSHOT.
Core BOM 2 et Extensions BOM 2 sont des candidats locaux, pas des dépendances disponibles. Il reste notamment à qualifier/publier les composants Boot 4 manquants (Commons, Security, Events, Web Errors et extensions concernées), puis contrôler la composition complète depuis les artefacts distants. Ne pas deviner une stable en retirant SNAPSHOT ou en soustrayant un patch.
La nouvelle composition Core Boot 4 doit prendre en compte le catalogue corrigé de DB 2.1.0, pas présenter DB 2.0.0 comme fournissant ce bootstrap. Events Boot 4 reste également un candidat distinct de la stable Events 2.0.0 Boot 3.
Gates de composition :
- Chaque GAV est stable, existe réellement et possède son contrat/sa preuve.
- Aucun mélange non qualifié Spring 6/7 ou Boot 3/4 dans le graphe final.
- POM seul et métadonnées Gradle qualifiés séparément.
- Tests des consommateurs représentatifs, puis autorisation de publication du BOM.
- Adoption indépendante par application ; aucun bump automatique des produits.
4. Correctifs : symptômes, causes et limites¶
| Release | Symptôme et cause racine | Correction / preuve | Ce qu'elle ne résout pas |
|---|---|---|---|
| DB 1.0.14 | Sources tenant permissives, routage/nettoyage et quotas concurrents insuffisamment sûrs | Sources signées cohérentes, rails fail-closed, éviction après reset échoué et réservations sous verrou ; reçu DB | Ni bootstrap complet du catalogue, ni RLS métier automatique |
| DB 2.0.0 | Ancien socle et admission de rôles administratifs trop larges | Boot 4, refus d'attributs et appartenances privilégiées ; Java 17/21 × PG 15/16 | Pas le bootstrap catalogue neuf ; les tests create-drop ne le prouvaient pas |
| DB 2.1.0, publiée | Catalogue absent en production, tests Hibernate masquant le manque de DDL ; ancien CHECK excluant INTERNAL | SQL/Liquibase explicite, validation structurelle, migration bornée du CHECK ; 119 tests × 6 cellules locales puis 6 CI, reprise des vrais 1.0.8/1.0.9 | Readiness métier, migration des données/ACL et GO produit restent applicatifs |
| Commons 1.0.10 | Besoin d'admission exacte et bornée des contextes D0 concurrents | Primitives consolidées ; reçu avec 101 tests Java 17 | N'active pas D0, la distribution des politiques ou Redis HA |
| Events 2.0.0 | Retour local pris à tort pour ACK broker, fermeture d'outbox prématurée | publishConfirmed et résultats distincts ; brokers/TLS/consommateurs qualifiés dans le reçu | ACK broker n'est pas traitement métier ; outbox/inbox restent à l'application |
| PDF 2.0.0 | Entrées de template insuffisamment bornées, inventaire et ordre Thymeleaf ; dépendances anciennes/superflues | Validation avant moteur, inventaire réutilisable, moteurs modernisés ; 55 tests par JDK, PDF physique et consommateurs distants | Pas de signature cryptographique promise ni de service/UI PDF livré |
| Notify 2.0.0 | Routages doublonnés, mutation de requête, résultats incertains mal distingués et transport implicite | Refus au démarrage, copie/validation, UNKNOWN, erreurs normalisées, HTTP dédié ; 60 tests par JDK, SMTP/HTTP réels et consommateurs | PROVIDER_ACCEPTED n'est pas DELIVERED ; compte fournisseur, callbacks et réconciliation à qualifier |
Recevoir un package ne signifie pas que toutes ses corrections sont backportées dans la ligne précédente. Les autres modules doivent disposer du même type de fiche : symptôme, cause, version corrigée, preuve, risque restant et action consommateur.
Sources de preuve :
- DB 1.0.14.
- DB 2.0.0.
- Candidat DB 2.1.
- Publication DB 2.1.0 · package 72581746.
- Reçu DB 2.1.0 : causes, migrations, CI et consommation distante.
- Commons 1.0.10.
- Events 2.0.0.
- PDF/Notify 2.0.0 et leurs reçus.
5. Adoption : protocole commun à chaque application¶
- Relever Java, Boot/Spring, moteur/version de base et GAV réellement résolus.
- Choisir le correctif utile dans sa ligne ; décider séparément d'une migration Boot 4.
- Vérifier les versions publiées, contraintes du BOM et transitives ; jamais de dépendance DYNORS SNAPSHOT, mavenLocal ou composite masquant une absence en CI.
- Adapter contrats/configuration/migrations, tester en environnement isolé, puis qualifier le graphe et l'image finale de l'application.
- Passer par Forge/SIRRAT et les références de secrets/configuration prévues ; une fixture locale ne vaut pas admission d'un template ou d'un couloir.
- Consigner GO/NO GO du consommateur et sa version adoptée. PACKAGE_PUBLISHED signifie « disponible », pas VERSION_BUMPED.
Ne pas pré-sélectionner aveuglément « la dernière version » dans Forge/TAKKU : filtrer d'abord par contrat et niveau de runtime. Aucun fallback vers l'ancien mécanisme permissif lors d'un rollback.
6. Tenue à jour de cette référence¶
Vérification de disponibilité pour Forge/TAKKU ou un développeur (lecture authentifiée, jeton injecté hors Git) :
curl --fail --header "PRIVATE-TOKEN: ${GITLAB_TOKEN_READ}" \
"https://gitlab.com/api/v4/projects/75907047/packages?package_type=maven&per_page=100"
Paginer les résultats (page suivante) pour un inventaire exhaustif ; remplacer le projet par 76017499 pour Extensions. La présence dans cette liste ne remplace pas le contrôle du POM, du contrat et du graphe consommateur.
À chaque release de module/BOM, mettre à jour cette page et le guide du composant avec : GAV, disponibilité registry, commit/MR/pipeline, empreintes, socle, tests, symptôme/cause/correction, limites et migration. Un candidat reste marqué candidat. Ne pas remplacer la preuve distante par un numéro lu dans un build local.
Core Maven : projet 75907047. Extensions Maven : projet 76017499. Lecture authentifiée, jeton hors Git ; PAT via Private-Token, CI via Job-Token. Ne pas vider les caches ou republier une stable pour masquer un défaut de résolution.