Ah oui, j’avais mal lu le code : les raw-specs sont déjà dans le livrable pour les chaînes gdev et gtest, je pensais qu’on les fournissais à l’exécution. J’ai modifié mon tableau en conséquence.
Soit, mais ça signifie que pour une release avec reboot de blockchain il faut re-livrer l’exécutable complet, et peut-être même faire une déclinaison du livrable par blockchain, donc avoir :
- duniter-gdev-600, basé sur le Genesis GDev-600 et supportant le Runtime ĞDev 600 en natif
- duniter-gdev-601, basé sur le Genesis GDev-600 et supportant le Runtime ĞDev 601 en natif
- duniter-gtest-100, basé sur le Genesis GTest-100 et supportant le Runtime ĞTest 100 en natif
- …
- duniter-gtest-102, basé sur le Genesis GTest-100 et supportant le Runtime ĞTest 102 en natif
- duniter-g1-100, basé sur le Genesis G1-100 et supportant le Runtime Ğ1 100 en natif
- …
Je suis parti du principe que les chaînes qui requièrent ces fichiers sont exécutées depuis le code source car exploitées par un développeur (donc compilation), tandis qu’un utilisateur exploiterait les chaînes gdev, gtest et g1 (donc exécution).
Cependant je garde la possibilité de préciser gdev-config.json (et équivalents pour gtest et g1) via la variable d’environnement DUNITER_GENESIS_CONFIG notamment pour les besoins de tests end2end et de CI (build des raw-specs à partir d’un dump “frais” de la Ğ1) qui peuvent vouloir préciser un autre fichier.