Mise à jour de Duniter-ts | Nouvelle version 1.6.13 RC

Oui je suis synchronisé je le vois avec la webUI. Comme je monte en compétence j’en profite pour tester et comprendre :slight_smile:

2 Likes

Suite à bug semi-critique qui causait la soumission au réseau de blocs invalident (et donc une chute de la difficulté malgré le grand nombre de membres calculant) il y a aura une version 1.6.12 car ce bug ne peut clairement pas attendre la 1.7 :

C’est là que les branches de version ont toutes leur utilité, ayant appliqué le correctif sur la branche 1.6 la version 1.6.12 ne sera pas impactée par les travaux en cours sur la branche dev :slight_smile:

Je livrerai la 1.6.12 dés que possible (au plus tôt vendredi soir sinon dans le WE ou en début de sem pro) !

1 Like

Si possible, inclus mon commit de test avec ton correctif. Ça assurera la non-régression aussi sur la branche 1.6.

Tu me fais signe si tu as besoin… même si je serai vraisemblablement pas très réactif ce week-end…

1 Like

10 posts were split to a new topic: Installation de duniter sur Yunohost

Tu a pusher sur la mauvaise branche :confused: c’est désormais sur la branche 1.6 qu’i faut appliquer tout ce qui concerne la 1.6, la branche dev contient des travaux en cours non stabilisés !

Du coup pour recopier ton commit sur la 1.6 j’ai fait :

git checkout dev
git reset HEAD~1
git stash
git checkout 1.6
gitn stash pop

Puis j’ai commiter :slight_smile:

Sinon il y a git cherry-pick, ça permet de conserver l’auteur notamment.

Bon peu importe, je ne savais pas que tu avais déjà fait la branche 1.6 à ce moment-là. Je m’attendais à ce qu’elle soit faite une fois la release officielle produite.

Je l’ai faite car j’avais besoin de me sentir libre de commencer a faire de la création sur dev pour la 1.7 :slight_smile:

Décidément je ne connais pas encore tout les rouages de git, merci je vais creuser ça :slight_smile:

@jytou je viens de livrer les .deb :slight_smile:

Tu peut livrer les versions windows et arm quand tu veut mais attention il faut que tu soit sur la branche 1.6 pas sur la branche dev ni encore moins sur master !

Pour tout ceux qui sont sous linux 64 bit, les .deb fonctionnent vous pouvez d’ores et déjà faire la mise a jours en 1.6.12 :

EDIT : le paquet pour linux x86 (32bits) est également disponible :slight_smile:

1 Like

Bon je crois que j’ai foiré un truc. Pour être sur la branche, il suffit bien de faire

git clone -b 1.6 git@github.com:duniter/duniter.git

Ou bien?

@jytou tu peut aussi cloner l’intégralité du dépôt puis te caler sur la bonne branche avec un :

git checkout 1.6

C’est pourtant ce que j’ai fait. Mais ça n’a pas fonctionné. Je relance et je regarderai demain.

Je viens d’installer sur un de mes nœuds raspi le .deb de la version 1.6.11 sur la version 1.6.10. Cela à l’air de fonctionner pour l’instant.
Ce nœud est sous Raspbian Stretch

Bon, après une matinée un peu mouvementée (urgences…) me revoilà. C’est bien

./release/new_prerelease.sh 1.6.12

qu’il faut lancer? Parce qu’à la sortie, il génère le fichier duniter-desktop-1.6.12-windows-x64.exe (sans « v ») mais ensuite il veut uploader le fichier duniter-desktop-v1.6.12-windows-x64.exe (avec un « v »).
Et la release arm est aussi avec un « v » et je n’ai pas eu de problème cette fois (en tout cas pas de problème apparent). Je suis en train de l’installer sur mon nœud gtest et ça a l’air de fonctionner.

Ah je soupçonne que quelque chose s’est mal passé au moment où @elois a fait la release (create release). Parce que tous les tags avant commencent par un « v » alors que la sienne n’a pas le « v ». Est-ce que ça viendrait du fait qu’on n’est pas sur la branche dev mais sur une autre branche? Pas trop le temps de fouiller aujourd’hui, désolé!

Oui il y a des pinceaux qui se mélangent là, c’est étrange :

Le préfixe « v » est ajouté automatiquement par les scripts. Pour rappel, la procédure indique (1) :

./release/new_version.sh 1.2.3

Puis (2)

./release/new_prerelease.sh 1.2.3

Ce qui est censé créer la pre-release « v1.2.3 » de tag « v1.2.3 ».

Pour info on a bien exactement le même code source (j’ai téléchargé les deux zip de sources et fait un diff -r, 0 différence).

À tous les coups @elois, tu fais des git tag manuels. J’ai bon ?

D’ailleurs si tu n’y vois pas d’inconvénient, je suggère que :

  • master intègre les fonctions stables de la version courante
  • dev intègre les fonctions stables de la prochaine version à venir
  • 1.6 intègre les fonctions stables de la version 1.6, ainsi que ses correctifs
  • <feature> intègre les fonctions instables ou en cours de dev d’une fonctionnalité à venir

Car là par exemple, les tests de la branche dev ne passent plus, et celui qui récupère le code sur cette branche pour y réaliser un développement (vu que c’est le workflow que l’on recommande) verra ses tests échouer, sans que cela ait un rapport avec ses propres développements.

3 Likes