Versions
avuru obs suit le versionnage sémantique (vX.Y.Z). Cette
page est la chronologie au niveau des versions ; pour les changements datés et
détaillés, voir le Changelog, et pour la suite la
Feuille de route.
:::note Pré-1.0 Jusqu'à la v1.0.0, les incréments mineurs peuvent inclure des changements cassants ; les incréments de correctif ne sont que des corrections. :::
Le tronc main. Direction prévue (voir la
Feuille de route) : les projets membres multi-clusters, une
compatibilité d'ingestion élargie avec des chemins de migration en double
écriture, un étiquetage automatique plus riche, et davantage de clients — une
source de données Grafana et une CLI portées par les jetons d'API livrés en
v0.5.
Piloter depuis l'interface. Presque tout ce qu'un opérateur changeait par
values.yaml vit désormais dans l'application : la collecte pilotable à
chaud (des interrupteurs par signal que le capteur suit en quelques secondes,
désactivée par défaut derrière un rôle délibérément étroit), les groupes de
services écrits dans Paramètres → Groupes, un mapping SSO groupe→rôle
éditable à côté des règles du chart en lecture seule, et des jetons d'API
personnels — hachés au repos, montrés une seule fois, résolus vers les
permissions vivantes de leur propriétaire : désactiver un utilisateur
désactive tous ses jetons. Le Tableau de bord devient l'écran d'accueil —
santé des groupes, topologie vivante, alertes actives et capacité Kubernetes
en une seule vue — et la carte des services affiche de vrais anneaux de
statut issus de la consolidation de santé, le p50/p95 par arête côté appelant,
le survol focalisé et des filtres partageables. Également : tri et filtres sur
l'écran Nœuds, et la correction de trois points d'API green qui répondaient
sans authentification. Les migrations de schéma 0016 à 0018 s'appliquent
automatiquement ; la montée de version est un helm upgrade ordinaire.
Version GitHub
· changelog.
Des comptes que vous administrez. La v0.2 créait les utilisateurs ; la v0.4
termine leur cycle de vie. Paramètres → Utilisateurs permet de modifier un
nom et des rôles, de réinitialiser un mot de passe et de supprimer un compte
selon la règle « désactiver d'abord », tandis qu'un nouvel onglet
Paramètres → Compte permet à chacun de changer son propre mot de passe — le
mot de passe actuel est exigé, les autres sessions sont fermées, la vôtre reste
ouverte. Ces opérations sont refusées aux utilisateurs SSO, dont l'identifiant
appartient au fournisseur d'identité. La revue de cette surface a refermé
trois portes d'entrée : un mot de passe local que l'on pouvait créer sur un
compte purement SSO, un verrouillage des connexions que la rotation d'adresses
IP contournait, et une connexion SSO capable de s'approprier l'e-mail d'un
compte local. Côté exploitation : une installation dont la migration de schéma
n'a jamais tourné se répare d'elle-même (hub.autoMigrate) et publie l'état
du schéma dans Paramètres → État ; un nom de base ClickHouse autre que celui par
défaut fonctionne ; green survit aux nœuds sans RAPL ; et la connexion
fonctionne derrière un reverse proxy qui réécrit Host. La montée de version
est un helm upgrade ordinaire.
Version GitHub
· changelog.
Correctif. Les valeurs d'images par défaut du chart n'ont jamais
correspondu à ce que publie le workflow de release — mauvais dépôts et un
format de tag jamais poussé : un helm install sans --set ne pouvait
résoudre ni le hub, ni l'UI, ni la passerelle, ni l'estimateur TDP. Les deux
moitiés sont corrigées ; l'estimateur green, livré sans aucun dépôt, se
comporte désormais comme ses homologues. Aucune migration de schéma, aucun
changement d'API ni de configuration.
Version GitHub
· changelog.
Une multi-tenance digne de confiance. La v0.2 avait sécurisé la lecture ;
la v0.3 verrouille l'écriture. Les projets deviennent quelque chose que vous
administrez — création, renommage et suppression depuis l'interface, les
entrées natives et déclarées dans la configuration restant en lecture seule —
et les clés d'ingestion par projet mettent fin à la confiance topologique :
les clés sont validées dans la passerelle et, en mode enforce, le projet de
la clé fait autorité sur le tenant, quel que soit celui que l'émetteur
déclare (le mode log par défaut ne change rien au pipeline : la promesse
OTLP « prise en charge directe » survit à la mise à jour). Une démo en
lecture seule en un clic connecte un visiteur en tant que lecteur restreint
sans que le mot de passe partagé n'atteigne jamais le navigateur. Le module
green fonctionne désormais sur les VM cloud dépourvues de RAPL, chaque
chiffre modélisé étant étiqueté estimé de bout en bout. Le plan de contrôle
de la collecte à chaud pose ses fondations — stockage de la surcouche, API
validée, droits RBAC restreints — et la couche de déploiement est renommée
avuruops → avuruobs (rupture ; voir le
guide de mise à jour).
Version GitHub
· changelog.
Profondeur et contrôle. L'installation en cinq minutes devient celle qu'une vraie équipe peut exploiter au quotidien : le hub est sécurisé par défaut (connexion, rôles Admin/Éditeur/Lecteur accordés par projet, SSO OIDC avec n'importe quel IdP), les signaux sont modulaires (un interrupteur par famille contrôle d'un bloc schéma, API, pipeline, collecte et interface), et le capteur peut être laissé activé en toute confiance — garanti par la CI. Quatre nouveaux modules s'appuient sur les données déjà collectées : le suivi des erreurs (problèmes dédupliqués et triables, plus une voie d'ingestion navigateur), la santé des services par groupes (niveaux de criticité avec propagation par dépendance), les alertes (webhooks protégés contre les SSRF sur les transitions de santé) et l'énergie & carbone (Wh/gCO2e par service, budgets, export prêt pour la CSRD). La santé réseau arrive sur les liaisons de la carte des services. Sous licence AGPL-3.0 à partir de cette version. Version GitHub · changelog.
La première version taguée : le coin. Un cluster Kubernetes neuf atteint une carte des services en direct en moins de cinq minutes sans changement applicatif — garanti par une porte CI. Les quatre niveaux de signaux v0.1 sont livrés — traces (complet), logs (basique), profilage CPU continu (allégé, sur option), métriques d'infra (support) — plus la migration OTLP « drop-in », un modèle par projet avec contrôles de collecte, et une inspection de traces approfondie. Version GitHub · changelog.
Une fois une version taguée, son entrée renvoie vers la
version GitHub et les
éléments correspondants du Changelog. Les versions sont coupées
selon le RELEASING.md du dépôt moteur.