Skip to main content
FireFlo usa versionado semántico estándar. Lo que te importa es lo que un número de versión promete y qué comprobar antes de tomar uno.

​
Qué significa el número

Tus notas de release acompañan cada build. Son la lista autoritativa de qué cambió; esta página trata sobre qué buscar en ellas.

​
Releases

El par actual es .
0.7.0 es donde esta tabla empieza, no donde FireFlo empieza. Releases anteriores existen y están en servicio; sus notas están disponibles desde support@fireflo.au. La historia publicada empieza aquí porque 0.7.0 abrió la línea de trabajo de facturación en la que el producto está actualmente.
Dos cosas que la tabla no te dirá por sí sola. La columna de panel de control muestra la revisión más nueva para ese release de gateway. El cuarto número es una revisión solo del panel y se mueve por sí sola. 0.7.3 tuvo tres de ellas. Cualquier versión de panel cuyos primeros tres números coincidan con el gateway es un par válido; el panel comprueba esto en runtime y lo dice cuando no coincide. Cinco releases de gateway en dos días no es un error. 0.7.0 abrió un trozo de trabajo de facturación, y cada release después cerró algo que el anterior expuso. Un defecto de facturación de segmentos, luego el emparejamiento de plantillas del que dependía, luego la gramática de placeholders, luego el trabajo de postpago, luego tres defectos en el camino de crédito. Los releases se agrupan cuando se está trabajando en una costura; así es como se ve.

​
Antes de actualizar

El patrón que merece la pena interiorizar: los cambios que duelen son los silenciosos. Un cambio disruptivo de API se anuncia; un valor por defecto cambiado no.
Un valor por defecto que se mueve cambia el comportamiento en cada despliegue que nunca estableció el valor. Que son la mayoría de ellos. Estas son las entradas que hay que leer con atención, más que las nuevas funcionalidades.
Habilitar el puerto de gestión movió /q/metrics de 8080 a 9000. Un job de Prometheus aún apuntando al viejo obtiene 404 en lugar de fallar sonoramente, así que un dashboard se lee como un sistema tranquilo en lugar de un monitor roto.
Las migraciones son solo hacia adelante. No hay migración de bajada, así que el camino de rollback es un restore en lugar de una migración inversa. Toma la copia de seguridad antes, no después.
La semántica de recibos ha cambiado dos veces de formas que fueron invisibles hasta que un cliente lo notó. level solía leer siempre 2, así que ACCEPTD se reportaba como un resultado; y el User-Agent en llamadas webhook cambió del valor por defecto del JDK a FireFlo/<version>, que importa a cualquier receptor con una lista de permitidos.
Si las cifras que un cliente puede ver van a cambiar, necesitan que se les diga antes de que pase. Con el número, la dirección y la fecha. Consulta Avisos a clientes.

​
Emparejamiento de versiones

El gateway publica su versión en ejecución en /ops/health, y el panel de control muestra tanto la suya como la del gateway.
Un par desemparejado se marca deliberadamente. El panel se degrada en lugar de romperse cuando habla con un gateway más viejo. Una columna simplemente cae de sus consultas. Pero una funcionalidad que aparece ausente por una brecha de versión se ve exactamente como una funcionalidad que está rota.Comprueba el par antes de investigar cualquier cosa que “debería estar ahí y no está”.

​
Reportar problemas

Todo va a support@fireflo.au. Lo que cambia es cómo lo enmarcas:
Redacta antes de compartir. Credenciales, system IDs, direcciones IP, números de teléfono y contenido de mensajes aparecen todos en configuración y logs. fireflo redacta lo que puede; una línea de log copiada a mano es tu propia responsabilidad.

​
Relacionado

Avisos a clientes

Cuando un release cambia lo que un cliente ve.

Migrar un despliegue

Viniendo de Jasmin o Kannel.