Mais en effet, je pense retirer tout code inutile afin d’avoir une base la plus propre possible, quitte à relancer un TestNet court (quelques jours, préparatoire à une monnaie de prod) afin de valider le code. En plus, ça aura l’avantage de chauffer un peu tout le monde avant la mise en prod et régler les derniers détails.
Il me semble que la simplicité est primordiale à la fois pour éviter les bugs, mais aussi pour que d’autres développeurs puissent contribuer à soutenir leur monnaie.
Oui excellente idée.
Peut être même pourrait t-on lors du lancement de la monnaie de prod, lancer une monnaie de test aux paramètres quasi-identiques.
Pour pouvoir, en cas de besoin ultérieur d’intervenir sur la monnaie de prod, faire dabord l’intervention sur sa monnaie teste jumelle pour voir si ça réagi comme prévu !
C’est ce qu’il faut faire, mais la monnaie de test devrait tout de même avoir un c test >> c prod le reste étant similaire. Normalement une bonne mise en prod passe pas une mise en environnement de test, vérification, avant de publier une release publique… Bon en pratique on ne le fait pas toujours, ce qui a tendance à créer des soucis… Mais il y a aussi des soucis à tarder à résoudre un bug… Donc bref…
merci pour l’explication technique, c’est intéressant !
Je pense que même pour une version de prod ça peut être mieux d’avoir un cœur duniter capable de vérifier les transactions sources sous plusieurs versions différentes.
Car en cas de besoin, on sera aussi amené à avoir parfois (certes très rarement) un changement de version même sur une monnaie de prod non ?
Oui mais je ne compte pas supprimer la mécanique des changements de version, simplement je ne souhaite pas que l’on ai des documents dont la version est antérieure à la v0.6 à venir car la 0.6 sera certainement notre point de départ pour une monnaie de prod.
Donc tout le code qui traite des documents précédents sera comme mort pour nous. Or cela apportera de la confusion aux futurs développeurs que d’avoir du code présent mais jamais exécuté.
Selon moi, il faut que cette monnaie de test ait un DU distribué chaque jour comme aujourd’hui, afin de tester facilement cette partie du code en cas de modification.
Édit et HS: Après réflexion, je me dis que le DU devrait également être distribué chaque jour sur la monnaie de production (avec “c” correct bien sur), Pourquoi?
Car j’ai peur qu’une partie des utilisateurs n’accède à la monnaie libre uniquement pour son DU, pour ensuite la revendre en monnaie non libre à chaque réception de DU.
Même si comme dit @Galuel, mes peurs n’appartiennent qu’à moi, mais si cela devait se produire,
fournir le DU chaque jour permettrait d’éviter une mise importante sur le marché de la monnaie libre en chaque début de mois/année
Et éviter une volatilité sur la monnaie inutile.
Imaginons également que l’on fournisse le DU une fois par an.
La perte de 10% d’un coup de la valeur d’un coin (en quantitatif) risque de générer des comportements curieux sur les places de marché.
Pour ces raisons je me dis qu’une distribution du DU le moins espacé possible me semble le moins risquée.
Mais ce n’est que mon ressenti, je suis loin d’être un expert en trading.
C’est juste, mais plutôt dans le sens de la nécessité de la continuité, il vaut mieux une production continue et régulière que saccadée tout simplement, tout en ayant un timing suffisamment “à taille humaine” permettant le contrôle et la réactivité. 24 heures semble donc une bonne unité temps pour la création.
2016-12-23T14:29:33+00:00 - info: SWITCH: get side chain #61052-000010EA27B8DFD60919BF616FB08547A09C31BF98855A4F6BFA0FEB5AF3BE9B...
2016-12-23T14:29:33+00:00 - info: SWITCH: revert main chain to block #60952...
2016-12-23T14:29:36+00:00 - info: SWITCH: apply side chain #61052-000010EA27B8DFD60919BF616FB08547A09C31BF98855A4F6BFA0FEB5AF3BE9B...
2016-12-23T14:29:36+00:00 - warn: Source T:F29550075E8509E4CA8814CE466E542F2DB22AC8412C4C56A1DABF3EFD49B8A8:11 is not available
2016-12-23T14:29:36+00:00 - warn: SWITCH: error %s httpCode=400, ucode=2015, message=Source already consumed
2016-12-23T14:29:36+00:00 - info: Block #60953 added to the blockchain in 141 ms
2016-12-23T14:29:36+00:00 - warn: Blockchain changed!
2016-12-23T14:29:37+00:00 - warn: Too high difficulty: waiting for other members to write next block
2016-12-23T14:29:37+00:00 - info: Pulling blocks from the network...
2016-12-23T14:29:39+00:00 - error: Blocks were not applied.
2016-12-23T14:29:42+00:00 - error: Blocks were not applied.
2016-12-23T14:29:44+00:00 - error: Blocks were not applied.
I notice https://github.com/duniter/duniter/issues/704 has been reopened and a commit by c-geek last week. Let me know if I can help out with testing a dev branch or anyhting… If not, what’s the ETA of v.0.61 ?
I bet on early January. It will be a v0.80 to mark the rupture with v0.60, since a lot of things will change in this version but still be compliant with TestNet and 0.60 nodes.
To circumvent the bug, you can try to reset + resync your node with the network. I know it is not a real fix, and I also know it would be better to release a 0.60.1 to make the fix. But we are so close to 0.80, and this version potentially fixes so many bugs, that I prefer to not release a minor patchy version and wait for the 0.80.
