Skip to main content
FireFlo utilise le versioning sémantique standard. Ce qui compte pour vous est ce qu’un numéro de version promet et ce qu’il faut vérifier avant d’en prendre un.

​
Ce que le numéro signifie

Vos notes de release accompagnent chaque build. Elles sont la liste faisant autorité de ce qui a changé ; cette page porte sur ce qu’il faut y chercher.

​
Releases

La paire actuelle est .
0.7.0 est où cette table commence, pas où FireFlo commence. Des releases antérieures existent et sont en service ; leurs notes sont disponibles auprès de support@fireflo.au. L’historique publié commence ici parce que 0.7.0 a ouvert la ligne de travail de facturation sur laquelle le produit est actuellement.
Deux choses que la table ne vous dira pas seule. La colonne control panel montre la révision la plus récente pour cette release gateway. Le quatrième numéro est une révision panel-only et bouge seul. 0.7.3 en a eu trois. Toute version panel dont les trois premiers numéros correspondent au gateway est une paire valide ; le panel vérifie cela à l’exécution et le dit quand ce n’est pas le cas. Cinq releases gateway en deux jours n’est pas une erreur. 0.7.0 a ouvert un morceau de travail de facturation, et chaque release après a fermé quelque chose que la précédente exposait. Un défaut de facturation par segment, puis la correspondance de templates dont il dépendait, puis la grammaire des espaces réservés, puis le travail postpayé, puis trois défauts sur le chemin du crédit. Les releases se groupent quand une couture est travaillée ; c’est à quoi ça ressemble.

​
Avant de mettre à niveau

Le motif à intérioriser : les changements qui font mal sont les silencieux. Un changement d’API cassant s’annonce ; un défaut changé non.
Un défaut qui bouge change le comportement sur chaque déploiement qui n’a jamais défini la valeur. Ce qui est la plupart. Ce sont les entrées à lire attentivement, plus que les nouvelles fonctionnalités.
Activer le port de gestion a déplacé /q/metrics de 8080 à 9000. Un job Prometheus encore pointé sur l’ancien obtient des 404 plutôt que d’échouer bruyamment, donc un tableau de bord se lit comme un système silencieux plutôt qu’un moniteur cassé.
Les migrations sont uniquement en avant. Il n’y a pas de migration en arrière, donc le chemin de rollback est une restauration plutôt qu’une migration inverse. Prenez la sauvegarde avant, pas après.
La sémantique des accusés a changé deux fois de manières qui étaient invisibles jusqu’à ce qu’un client remarque. level lisait toujours 2, donc ACCEPTD était rapporté comme un résultat ; et le User-Agent sur les appels webhook a changé du défaut JDK à FireFlo/<version>, ce qui compte pour tout récepteur avec une allow-list.
Si des chiffres qu’un client peut voir vont changer, il faut le lui dire avant que cela n’arrive. Avec le nombre, la direction et la date. Voir Avis clients.

​
Appariement de version

Le gateway publie sa version en cours sur /ops/health, et le control panel montre à la fois la sienne et celle du gateway.
Une paire non correspondante est signalée délibérément. Le panel se dégrade plutôt que de casser quand il parle à un gateway plus ancien. Une colonne disparaît simplement de ses requêtes. Mais une fonctionnalité qui semble absente à cause d’un écart de version ressemble exactement à une fonctionnalité cassée.Vérifiez la paire avant d’enquêter sur quoi que ce soit qui « devrait être là et ne l’est pas ».

​
Signaler des problèmes

Tout va à support@fireflo.au. Ce qui change est comment vous le cadrez :
Expurgez avant de partager. Identifiants, system IDs, adresses IP, numéros de téléphone et contenu de messages apparaissent tous dans la configuration et les logs. fireflo expurge ce qu’il peut ; une ligne de log copiée à la main est votre propre responsabilité.

​
Connexes

Avis clients

Quand une release change ce qu’un client voit.

Migrer un déploiement

Venant de Jasmin ou Kannel.