# Montées de version

## Versions épinglées

| Service         | Version                                       | Remarque                                |
| --------------- | --------------------------------------------- | --------------------------------------- |
| OpenObserve     | `v0.14.4`                                     | épinglée                                |
| Collecteur OTel | `0.137.0`                                     | épinglée                                |
| Umami           | `postgresql-v2.19.0`                          | épinglée                                |
| Matomo          | `5.3-apache`                                  | tag mineur, suit les correctifs         |
| MariaDB         | `11.4`                                        | tag mineur                              |
| PostgreSQL      | `16.4-alpine` (Umami), `17.4-alpine` (Rybbit) | versions imposées par l'amont           |
| ClickHouse      | `25.4.2-alpine`                               | épinglée                                |
| Redis           | `8.6.4-alpine`                                | épinglée                                |
| Rybbit          | **`latest`**                                  | **à corriger avant tout usage distant** |

`latest` pour Rybbit est une dette assumée du POC : l'amont ne publie pas de tag de version stable
évident. Un déploiement distant doit épingler une empreinte (`@sha256:…`).

Côté applicatif, `@opentelemetry/sdk-node` est en `0.300.x` : les versions `0.x` de l'écosystème
OpenTelemetry **cassent régulièrement leurs API**. Deux exemples déjà rencontrés dans ce POC :
la classe `Resource` remplacée par `resourceFromAttributes`, et `BatchLogRecordProcessor` dont la
signature est passée d'un exportateur à un objet d'options. Toute montée demande de relire le
journal des changements, pas seulement de lancer les tests.

## Marche à suivre

1. Sauvegarder, et **vérifier la sauvegarde**.
2. Monter **un service à la fois**, jamais la pile entière.
3. Relancer `pnpm telemetry:test` après chaque montée : il interroge les données, donc il détecte
   une régression d'ingestion qu'un contrôle de santé laisserait passer.
4. Vérifier le journal du service pour les migrations de schéma.

## Retour arrière

Possible pour les conteneurs applicatifs, **pas** pour les schémas de base de données. Une montée
de Matomo, d'Umami ou de Rybbit qui migre le schéma n'est pas réversible : seul le retour à la
sauvegarde l'est.

## Mises à jour automatiques

Renovate peut **proposer** les montées. Il ne doit pas les appliquer sans contrôle sur
l'infrastructure d'analytics : une migration de schéma déclenchée automatiquement n'est pas
rattrapable.