La partie intéressante d’une release, ce n’est presque jamais le changelog. C’est ce que couper la release t’apprend.

cidx, mon runner CI/CD déclaratif, vient de sortir en v2.1.0 — 11 commits depuis la v2.0.0, après 59 jours de silence. Il y a des features et des correctifs, je les liste plus bas. Mais la sortie la plus utile de cette release, ce sont sept issues que j’ai ouvertes pendant la coupe du tag — parce que j’ai coupé le tag avec l’outil de cidx lui-même.

Ce qui a été livré (la partie courte)

  • probatum preset — un nouveau preset intégré pour la phase de test.
  • pr edit — mettre à jour titre/corps d’une PR sans repasser par l’UI de la plateforme.
  • Six correctifs : cargo-audit en binaire préconstruit (phase sécu plus rapide), fallback en pull anonyme quand un registre rejette des credentials périmés, épinglage du cidx bootstrappé à la version qui l’a généré (fini la dérive @latest), cpw qui attend que le workflow CI démarre avant de rendre la main, préfixe de branche dérivé du type de commit, et check drift qui résout le fichier de workflow au lieu de deviner .github/workflows/ci.yml.

C’est le diff. Il est correct, il est utile, il est ennuyeux. Passons à la vraie histoire.

Se couper une release avec son propre outil

cidx sait couper une release : cidx release create. Alors je l’ai utilisé pour couper la sienne. Et c’est exactement là que ça devient intéressant — parce qu’un outil sur une démo bien rangée ne montre jamais ses accrocs. Un outil sur une vraie tâche à enjeu (poser un tag, pousser une version) les montre tous.

Sept, ce jour-là. Filés le jour même, tag encore chaud :

  • #184 — release create pousse le commit de version directement sur main… et se fait rejeter par la protection de branche. La récup est une séquence PR-puis-cherry-pick-puis-tag à la main. L’outil ne connaît pas les règles du repo sur lequel il tourne.
  • #185 — release preview calcule la version depuis trois sources (VERSION, .cz.toml, dernier tag) sans les réconcilier. Premier run : il propose v1.8.0 alors que le dernier tag est v2.0.0. Une seule source de vérité manquait.
  • #186 — release tag prepare attend un éditeur… sans détecter qu’il n’y a pas de TTY. Il hang.
  • #180 — cpw annonce « rien à committer » pour des fichiers non suivis.
  • #178 — le cidx.toml de cidx a maintenant une vraie dérive, précisément parce que le correctif #177 permet enfin à check drift de la voir : des phases docker et release déclarées, sans jobs correspondants dans ci.yml. L’outil qui trouve son propre décalage.
  • #175 — la détection de breaking-change lit type!: dans les commits parsés… mais la regex du parser ne capture pas le !. Bug latent.
  • #174 — une vingtaine de hints pointent encore vers le namespace cidx action … déprécié.

Aucun de ces sept ne se voit en lisant le code. Chacun est un nœud qu’on ne sent qu’en tirant sur la corde pour de vrai.

Pourquoi c’est le loop qui marche, pas le loop qui casse

Le CLAUDE.md de cidx pose une règle : « on mange notre propre cuisine ; si une commande a une mauvaise UX, ça devient la priorité suivante. » La v2.1.0 est cette phrase en action. La release ship, et le backlog d’outillage de release grossit le même jour. Ce n’est pas un échec de la release — c’est le seul moyen honnête de savoir où l’outil fait mal : le prendre au sérieux sur sa propre tâche la plus sensible.

Et il y a une nuance qui compte. « Dogfooder », tout le monde le dit — « on utilise notre propre outil ». La version honnête, c’est autre chose : on s’en sert sur le truc qui fait peur, et on écrit publiquement, le jour même, chaque endroit où il a mordu. Les accrocs ne sont pas cachés sous le tapis en attendant qu’un utilisateur les trouve. Ils sont la roadmap, datés, numérotés.

Ce qui vient

Le backlog v2.1.0 → v2.2.0, c’est déjà ces sept issues, plus la décision sur la dérive de #178. La prochaine release sera plus calme côté features et plus chargée côté plomberie de release : détection de TTY, une source unique pour « la version courante », un push conscient de la protection de branche, et le nettoyage des hints dépréciés.

Petites releases, boucle serrée. Et à chaque tour, l’outil sait un peu mieux où il fait mal — parce qu’on a osé s’en servir là où ça compte.