Mise à jour forcée de Cesium (en douceur)

Clients Cesium
1

Nous en avons discuté pendant les RML16 mais pas vraiment pris de décisions claires.

Voulons nous forcer la mise à jour de Cesium une fois la migration v2 effecuté ?
Mon avis est que oui il faut vraiment faire ça pour éviter toute confusion: Migration V2 _ comment ne pas perdre des Junistes - #7 par poka - Mise à jour V2 - Forum Monnaie Libre

Dans cette optique, je propose de pousser cette feature le plus tôt possible dans Cesium v1 pour s’assurer qu’un maximum d’utilisateur ai effectué cette mise à jour le jour J.

Concrètement ce que je ferais au plus simple:

  • Héberger un json avec un boolean sur un serveur contrôlé par les devs avec une simple route.

    {
  "migration": false
}

  • Fetch ce json à chaque démarage de Cesium, et avant toute chose, comme première action, check si ce boolean est false, on continue normalement, sinon, on affiche un popup bloquant:

    Veuillez mettre à jour Cesium avant de continuer.
    En savoir plus
    Bouton d’action ouvrant le store google ou apple: Mettre à jour

  • Si la route est inaccessible ou qu’un timeout est atteint, soit:

    • on affiche un message d’erreur et on redirige l’utilisateur sur ce forum (option que je préfère)
    • on continue le démarrage de Cesium normalement.

Éventuellement ajouter un lien pour installer une version legacy de cesium v1 sur la page web en savoir plus.

Si on veut plus de modularité on peut mettre le texte de la popup avec le lien en savoir plus dans le json directement, mais il faut alors penser à toutes les traductions dans le json:

{
  "migration": false,
  "fr": "Veuillez mettre à jour Cesium avant de continuer.",
  "fr_link": "https://monnaie-libre.fr/migration-v2/",
  "en": "Please update Cesium before continuing.",
  "en_link": "https://monnaie-libre.en/migration-v2/",
  "es": "Por favor, actualice Cesium antes de continuar.",
  "es_link": "https://moneda-libre.org/migration-v2/",
  "it": "Si prega di aggiornare Cesium prima di continuare.",
  "it_link": "https://monnaie-libre.it/migration-v2/",
  "de": "Bitte aktualisieren Sie Cesium, bevor Sie fortfahren.",
  "de_link": "https://monnaie-libre.de/migration-v2/",
  "ko": "계속하기 전에 Cesium을 업데이트하십시오.",
  "ko_link": "https://monnaie-libre.ko/migration-v2/"
}

Personnellement je suis plutôt partisan des textes en dur dans l’app, moins source de bug, fetch plus rapide car plus léger, et on reste sur du wording le plus simple, générique et direct possible avec tout le blabla sur une page web en savoir plus.

ping @kimamila qu’en penses-tu ?

1 Like
2

Évitons le terme “Forcé”, je pense qu’il est préférable de dire : “mise à jour automatique”, ce serait plus clair, et plus proche de la réalité.

1 Like
3

Non c’est bien le bon terme, ça ne sort pas du chapeau, on l’utilise au boulo: forced update - Wiktionary, the free dictionary

Mise à jour forcée
Une mise à jour est requise avant que l’utilisateur soit autorisé à continuer à utiliser le logiciel.

Automatique ne convient pas car ce n’est pas le cas: une action est requise par l’utilisateur. Césium ne se mettra pas à jour tout seul.

Mise à jour obligatoire si vous préférez, ou quelque chose de ce champ lexicale.

Dans la communication vous n’êtes pas obligé de le nommer, simplement “Césium vous proposera automatiquement (là ça marche) de le mettre à jour vers la version 2 de manière à profiter d’un confort optimal au niveau des genoux ect…”

A la limite le terme Demande de mise à jour fonctionne aussi et peut sembler moins violent.

1 Like
4

Une proposition :
“Pour continuer d’utiliser la G1 pour vos échanges et poursuivre vos certifications, Césium vous invite à le mettre à jour en cliquant sur ce bouton”

ou il vous est proposé de…

1 Like
5

Je parlais de la communication hors app.

Pour la popup inapp, je pense qu’il vaut mieux rester minimaliste:

Titre: Mise à jour requise.
Corps: veuillez mettre à jour Césium avant de continuer
En savoir plus
Bouton mettre à jour.

3 Likes
6

Ok, de toute façon pour la communication cela fera partie de la 3eme phase 'comment cela va se passer"…

7

S’il y a un bug quelque part, ça risque de bloquer Cesium.

Si les gens demandent à quoi sert la màj qui introduit à l’avance le test, on leur dit quoi ? Que c’est parce qu’on les prend pour des cons ? En plus ça pourrait alimenter les théories du complot du putsch des devs.

Certaines personnes pourraient aussi vouloir explorer la Ğ1 après migration, pour je ne sais quelle raison (nostalgie, historique, vérifier que les données sont les mêmes).

Je passe les détails, mais cet été j’ai utilisé une appli pour mes billets de train. L’appli ayant demandé une màj obligatoire et la nouvelle version plantant au démarrage, j’ai dû repayer le billet plain tarif.

Donc svp évitez d’implémenter l’équivalent d’un DRM. Il faut qu’il y ait un moyen (découragé mais accessible) d’outre-passer.

De toute façon les complotistes anti-migration sauront bien installer une ancienne version s’ils veulent rester en v1. Les autres comprendront qu’il faut mettre à jour s’il faut passer par “Paramètres avancés” et par un avertissement. Un petit panneau attention pourrait rester affiché sur le côté en permanence, pour rétablir la modale au clic.

1 Like
8

Je ne suis absolument pas d’accords avec ce raisonnement.

On leur dit simplement que le choix de les laisser continuer d’utiliser Cesium v1 après la mise à jour v2 se traduit par leur laisser le choix de se perdre sur un réseau obsolète.
Cette mise à jour sert à prévoir la mise à jour v2 dans les meilleurs conditions tout simplement.

Ce serait ne pas prévoir les choses correctement à l’avance qui serait les prendre pour des cons.

ignoratio elenchi

Oui c’est bien ce qui est indiqué dans ma proposition de base, c’est une solution qui avait été proposé par @kimamila aux RML16:

La version Cesium v1 serait donc une autre version à installé spécifiquement pour les cas à la marge, comme les nostalgique ou les complotistes.

Oui et donc ? On va juste ne rien faire, dans le but de faire plaisir aux complotistes ?

Oui c’est bien le but de cette manoeuvre.
Ne pas faire ceci serait se foutre de la gueule des utilisateurs en leur laissant un jolie piège de pouvoir utiliser le réseau déprécié après la migration. Je trouve que ça révèle pas mal de chose côté dev.

Avec cette feature on s’assure simplement d’être ceinture bretelle concernant l’expérience utilisateur post migration.

C’est bien pour ça que j’ai prévus les cas d’erreurs dans mes specs.
C’est pour ça que je suis pour un simple json avec un boolean. On peut doubler la route sur un autre serveur, en cas d’erreur de fetch cesium check la route de secours, et sinon il continue le démarrage normal.

4 Likes
9

Effectivement ça me semble une bonne idée de proposer d’installer une “version 1.99” de Cesium avec un moyen de savoir si la migration a eu lieu, et même de proposer à l’utilisateur d’envoyer un message Cesium+ à un compte contrôlé par les devs pour informer que cette version est installée.

Les version numérotées normalement (1.7.14, 1.7.15…) seraient les versions historiques sans modification liée à la v2 donc resteraient sans analytics.

Comme nomenclature, je ne parlerais ni de mise-à-jour “forcée”, “obligatoire”, ou “automatique”, mais plutôt d’une mise-à-jour “de confort” ou “de prudence” parce qu’elle permet tout simplement à un utilisateur d’éviter d’utiliser la Ğ1v1 alors qu’il souhaite utiliser la Ğ1v2. Et dans les store d’application (google play, app store, extensions navigateur…), les vieilles versions seront toujours installables si le store permet de rollback (comme fdroid par exemple sur cette capture)

image
image1880×1232 191 KB

Pour les store qui ne permettent pas de rollback, tant pis, les utilisateurs passeront par l’apk, le xpi, le deb ou autre… Si des gens veulent publier une appli legacy sur l’app store, ils peuvent bien entendu le faire, le code source est libre !! (c’est juste que vu la galère que c’est de publier une app sur Apple on va pas faire deux fois le travail juste pour du legacy)

Autre chose, ce serait chouette d’inclure dans cette version 1.99 de quoi trouver les infos sur la v2.

3 Likes
10

Ce fichier serait de toute façon utile. Dans Cesium v1.99, Cesium v2.0, Duniter Panel, ou même Ğecko. Il devrait intégrer des informations supplémentaires :

// avant migration
{
   "migration": false
}
// après migration
{
   "migration": true,
   "genesis_hash": "0xc184c4ccde8e771483bba7a01533d007a3e19a66d3537c7fd59c5d9e3550b6c3",
   "genesis_timestamp": 1741392000,
   "last_g1_v1_block_number": 811481,
   "rpc_bootstrap": ["wss://g1.p2p.legal/", "wss://g1.coinduf.eu"...]
}

On peut même avoir un fichier par réseau gdev.json, gtest.json, g1.json avec un champ active: true (plus parlant que “migration”). Ou même un fichier networks.json avec trois champs gdev, gtest, g1 qui contiennent ce qu’il y a ci-dessus.

L’utilité serait :

  • Le hash du genesis permet de vérifier si un endpoint RPC est sur le bon réseau.
  • Le timestamp du genesis permet de vérifier la cohérence des infos.
  • Le numéro du dernier bloc v1 peut être affiché à l’utilisateur dans Cesium v1.99 pour s’assurer de ce qui est antérieur ou postérieur.
  • La liste de bootstrap RPC est censée permettre de trouver d’autres endpoints RPC, endpoints squid, et autre (cf Liste des endpoints). Si ce n’est pas rendu accessible via RPC, il faudra mettre l’url des services qui remplacent, ou mettre à jour ce json régulièrement.

Et l’avantage d’avoir plusieurs réseaux est qu’un client v2 peut se connecter par défaut à g1 si actif, ou s’il est inactif proposer à l’utilisateur de se connecter à un réseau de dev à la place.

[edit] c’est fait : nodes / networks · GitLab
[edit 2] est-ce que ça te va @poka si on renomme ce sujet “Mise à jour en douceur de Cesium” dans la même idée que la “migration douce” ? (V2S: smooth gradual migration (clients and indexers side))

2 Likes
11

Oula moi je ne parlais que d’un ticket Quick win rapide à faire pour un use case très précis.

Là on rentre dans du dev sur césium v1 que je trouve superflue. Je pourrais dev ma version simple, mais pas celle proposé.

Je ne vois pas trop l’intérêt de traiter toutes ces info sur césium v1. Soit on migré soit on migre pas, et on est sur la Ğ1, pas la gdev, c’est pour les user qu’on fait ça.

Mais bon à vous de voir.
Pour le terme en douceur oui comme vous voulez. Ce sera une mise à jour forcé en douceur.

1 Like
12

Il faudra quand même que les beta-testeur sur la Gtest, sache s’ils sont encore en Gtest, ou Ğ1.

1 Like
13

Ça peut rester quick win. Je dis juste qu’avoir un enpoint unique avec migration true/false peut servir à tous les clients. Voilà le fichier mis en place, maintenant il ne reste qu’à implémenter la lecture de g1.json/active dans Cesium v1.99 pour savoir si on affiche un popup bloquant. Les gens qui veulent suivre le mouvement n’ont qu’à mettre à jour pour être sûrs de ne pas louper la migration. Ceux qui veulent rester n’ont qu’à ne pas mettre à jour.

Et Cesium v2 reste installable à côté via l’APK pendant la phase de test, et le jour de la migration, on publiera la version 2.0 de Cesium sur les store pour qu’une mise à jour standard remplace la 1.7.14 ou 1.99.

1 Like
14

Je ne comprends pas, pour ce genre de cas il faut utiliser des flavors, c’est à dire différent builds d’une même app en mode prod/test/dev.
Ceux qui sont sur l’app Cesium prod seront mis à jour vers Cesium² prod quoi qu’il arrive. Si ils ont set des endpoints de gtest sur une app de prod c’est qu’il savent ce qu’il font et c’est donc leur problème.

Pour le reste, seul le champ last_g1_v1_block_number est cité pour être utilisé pour Cs1, en l’occurence:

Me semble vague, je ne vois aucun intéret à afficher le numéro de bloc au gens (déjà tout court de manière générale…) au moment de l’affichage du popup de mise à jour…
Ca nécessite plus de dev custom côté Cs1 pour du dev poubelle!

Tout le reste c’est un autre usecase, donc un autre json, autre endpoint, utile uniquement pour les cliens v2s, ça n’a aucun rapport (ou j’ai mal compris kkchose hein dis moi).

L’intéret de cette feature c’est d’éviter au maximum le risque de bug sur Cs1 au moment de la migration, donc un simple json avec 1 boolean true/false, avec une redondance de route, avec une action très simple à faire, et un popup basique.

15

Je pense qu’on va proposer à tous les utilisateurs de tester un mois avant avec la bascule à blanc, pour leur permettre de se familiariser, et pouvoir répondre à leurs questions.

Donc ces gens auront déjà installé cesium2, mais pas sur la Ğ1. Il faudra les prévenir qu’il faut qu’ils passent au monde réel après avoir fait mumuse.

2 Likes
16

Donc je me répète, les testeurs doivent être sur un flavor dev. Donc rien à voir avec le appid de césium.

On ne va pas intégrer cette feature au appid cesium-dev ni cesium-test, si ?

17

:rofl:

18

Vive la novlangue hein!

Aussi je rappel que le but de la manoeuvre est que l’appid de Cesium2 soit le même que celui de Cesium1.
Donc les testeurs testant Cesium2, si tant est qu’ils testent, le font nécessairement sur un appid de test.

CS va devenir Cs2.
Donc je maintiens vraiment ma position sur ma proposition.
Dis encore autrement les testeurs auront deux Cs2 sur leur appareil après migration. Il convient donc de rebrander la version actuelle en test.

19

Celui de la Ğdev et celui de la Ğ1 ?
La Ğdev continuera d’exister après migration ?

20

Oui, on en a besoin pour tout casser tester les développements.

2 Likes