Vu que la release windows prend le dernier tag créé et que git describe --tags 1.6 renvoie 1.6.12 (sans le « v »), il faudrait supprimer ce tag. Mais quand je vais sur github, le tag en question n’apparaît que dans la page release, je n’arrive pas à le voir ailleurs (ceci dit, je suis un bleu en github donc j’ai peut-être mal cherché.
Exact je saurais désormais qu’il faut tagger avec un v. Je pense que la seule solution propre est de créer un commit de version 1.6.13 et de relivrer !
@jytou tu peut faire un :
./release/new_version.sh 1.6.13
et relivrer !
Oui très bien, je viens de revert mes deux commit de dev de nouvelles features et de les placer dans la branche ws2p-v2
2 Likes
Avant de faire une bêtise, dans le cas présent c’est bien :
git push origin 1.6 --tags
?
non juste git push origin --tags 
yes j’ai refait un clone -b, je suis pas encore très joueur avec git…
1 Like
oui je te confirme que le commit de version est bon, il est bien sur la branche 1.6 et bien avec un v, tout est bon tu peut passer a l’étape de livraison
1 Like
C’est fait. 
1 Like
nickel je viens de tester le paquet duniter-server-v1.6.13-linux-x64.deb et il est bon
1 Like
après confirmation par des utilisateurs de windows et arm que toutes les build sont bonnes je pense passer cette version 1.6.13 au rang de version officielle en début de semaine
Si un nouveau bug critique ou semi-critique est détecté on patchera dés que possible mais la version semble très stable depuis une semaine (outre le bug #1190)
1 Like
Autre pratique que je suggère, déjà énoncée par Inso : quand on estime avoir terminé une feature, demander une révision par les pairs (peer review) avant de fusionner notre branche sur dev.
Je vais personnellement appliquer cette suggestion à moi-même, et demanderai à @elois et @inso leur relecture à chaque fois. Si d’autres veulent être mis dans la boucle, dites-le moi simplement.
Ainsi cela permettra un meilleur suivi de l’évolution du code, et aussi formuler notre fonctionnalité permet souvent de l’affiner. Bref c’est une bonne pratique qui, maintenant qu’on a un code stable, peut tout à fait être intégrée
4 Likes
Merci de faire ainsi car je fait tourner mon nœud sur la branche de dev.
Et, en effet, les connexions WS2P ne fonctionnaient plus.
Ok, j’ai passé cette variable à true :
"bmaWithCrawler": true,
et mon nœud se synchronise de nouveau derrière sa connexion mobile.
C’est une nouvelle variable ?
J’ai pas suivi les développents récents.
C’est curieux car j’ai 2 nœuds sur dev (maintenant su ws2p-v2) et les connexions ws2p fonctionnent très bien, d’ailleurs ils restent synchronisés sans bma ! Si les tests ne passent plus c’est parce que je doit les réécrire car il testent l’ancien comportement,et j’ai refondu entièrement l’algo de choix des connexions donc le comportement a changé 
Oui le crawler BMA est voué a disparaitre je l’ai rendu optionnel pour la transition, afin que les noeuds 1.5 restent synchro, mais lorsque la migration du réseau en 1.6 sera complète il faudra les désactiver pour voir si ws2p se suffit à lui-même 
Ok
Je n’ai toujours pas réussit à faire fonctionner un nœud en WS2P-only. Je devrait réessayer depuis le temps.
J’ai l’impression qu’il faut une découverte des nœuds via BMA au préalable. N’est-ce pas ?
Comment les nœuds WS2P-only font-ils pour se découvrirent?
C’est effectivement un point faible de ws2pv1 que j’aimerais améliorer en ws2pv2 avec une sorte de connexion temporaire qui ne servirai qu’au partage de fiches de pairs avant de s’interrompre et qui ne pourrais pas être refusée (sauf aléas réseau bien sur).
Mais aujourd’hui ws2p-only fonctionne déjà a condition d’activer ws2p Privé (ce qui est le cas par défaut), le noeud partage alors sa fiche de pair avec les connexions OUTCOMING qu’il établi, et donc il faut du temps avant de recevoir sa 1ère connexion INCOMING le temps que le réseau te “découvre”.
EDIT Si tu est sur le réseau g1 il y a un autre problème c’est que les nœuds ws2p public sont encore peu nombreux et saturés, car la majorité des nœuds miroirs sont encore en 1.5 et plus d’un tiers des nœuds membres également, donc ton noeud a du mal a trouver une place disponible sur un noeud ws2p public. Ce problème sera je pense résolu de lui-même lorsqu’il y aura davantage de nœuds ws2p public sur le réseau (et donc quand la version officielle sera déployée, car beaucoup d’utilisateurs non testeurs sont encore sur la 1.5.9)
1 Like
Télécharger Duniter-ts v1.6.13 RC
Les changements par rapport à 1.6.11 :
- Résolution du bug semi-critique #1190
C’est tout ! Cette mise à jours est essentielle pour les nœuds membres car le bug #1190 peut vous faire générer des blocs incorrect et vous ne pouvez donc plus participer au calcul des blocs !!
Si tout va bien, cette version 1.6.13 sera portée au rang de version 1.6 officielle en début de semaine
1 Like
Installé sur un nœud. Pour l’instant pas de problème.
Configuration: Raspi2/Stretch sans yunohost
Concernant cette nouvelle option, je trouve que ça a ça place dans un module.
Je vois pas ce que Tor viens faire dans le cœur de duniter
2 Likes
Ça fera du bien à l’équipe de développement.
J’avais déjà proposé la review par les pairs à Cédric. C’est ainsi qu’on fonctionne chez YunoHost, bien que ça soit un peu lourd.
Jusqu’à présent cgeek se débrouillait bien sans tout casser et en injectant de nouvelles fonctionnalités bien fonctionnelles.
Dès-lors que plusieurs développeurs s’y mettent. La qualité du développement peut être amélioré autant par la qualité du code que sur l’accord de principe de l’implémentation.
3 Likes