Maintenant ces bases posées (moi aussi ça m’a fait du bien de tout remettre à plat, tout n’est pas limpide dans ma tête), je peux proposer un schéma de branches de release.
- une branche master qui contient toutes les contributions
- pas de numérotation du runtime
- pas de numérotation du client
- une branche par réseau (
gdev-a,gdev-b,gtest,g1) qui contient uniquement ce qui est pertinent pour ce réseau mais pas ailleurs- les
g1-data.jsonpour alimenter le genesis - les “raw chainspecs” intégrées au binaire pour alimenter la commande
duniter --chain=<network> - les mises-à-jour successives des bootnodes dans les chainspecs au cours de l’évolution des nœuds publics
- des commits de merge de
masterlorsque l’on veut publier un nouveau client pour ce réseau (donc informer les gens qui ont des nœuds sur ce réseau de la disponibilité d’une mise-à-jour) - des commits de numérotation de ce client intégrant le nom du réseau (ex
1.2.3-gtest)
- les
- des branches de release du runtime basées sur master
- ces branches ne contiennent qu’un commit de numérotation du runtime et du client d’après ce runtime (ex
900et0.0.0-900) - elles mènent à la publication de trois runtimes, prêts à être utilisés pour des runtime upgrade sur chaque réseau (la seule différence entre le runtime
gtestetg1étant des constantes du runtime) - elles mènent à la publication d’une client non destiné à un réseau existant (pas de chainspecs) mais destiné uniquement à des réseaux locaux de dev pour des environnements de dev (
duniter --dev) mais qui démarre en utilisant ce runtime (gdev, il ne devrait pas y avoir de raison d’utiliser un autre runtime pour du dev local)
- ces branches ne contiennent qu’un commit de numérotation du runtime et du client d’après ce runtime (ex
Les avantages que je vois à ce schéma sont :
- on met le minimum de choses sur les branches de réseau et on peut abandonner la branche si on abandonne le réseau
- les numéros de version sont toujours clairs, on évite de se retrouver avec une version numérotée qui n’est pas ce à quoi on s’attend
- on identifie clairement les binaires (et images docker associées) destinées à un usage réseau de celles dédiées à un usage de dev
Mais je veux bien des retours et je pense que @cgeek aussi vu que ça concerne un peu tous les devs de clients, forgerons, et administrateurs de noeud.