Passer au contenu principal
Format de référence pour les release notes GitHub de tale-project/tale. La slash-command /release rédige les notes selon cette spec, et le lien “What’s new” dans le produit y dirige les utilisateurs.

​
Pourquoi cette spec

Les opérateurs et utilisateurs comptent sur les release notes pour savoir :
  • si un correctif de sécurité les concerne ;
  • si un changement de modèle ou fournisseur modifiera leurs sorties de workflow ;
  • si une mise à jour demande des étapes manuelles.
Des sections cohérentes — dans un ordre cohérent — rendent facile de scanner une release pour ces trois points sans lire chaque bullet.

​
Sections obligatoires

Inclure seulement les sections avec contenu. Toujours dans cet ordre :
N°Titre de sectionPortée
1## 🔒 Securitycorrectifs CVE, patchs de dépendance, durcissement auth/session/crypto, gestion de secrets
2## 🤖 Model & Providerswap/upgrade/dépréciation de modèle LLM, changements de config fournisseur qui modifient la sortie
3## 💥 Breaking Changessuppression/renommage d’API, migrations manuelles de schéma, fonctionnalités retirées
4## 🚀 Featuresnouvelles fonctionnalités visibles par l’utilisateur
5## ⚡ Performancegains de performance mesurables à mettre en avant
6## 🛠 Improvementsaméliorations non breaking, polish UX
7## 🐛 Fixescorrectifs de bugs (non sécuritaires)
8## 📝 Otherdocs, refactors, chores — avec parcimonie

​
Cadre obligatoire

Chaque release doit contenir au minimum :
  1. Titre : v{version} — {tagline court}, ex. v1.6.0 — Usage analytics & multi-tenancy.
  2. Résumé : 2–3 phrases en tête décrivant quoi et pourquoi. Sans emoji.
  3. Instructions de mise à jour : 
    ## Upgrade

Run `tale upgrade` to update the CLI, then `tale deploy` to apply the new version.
    Les deux étapes sont nécessaires — tale upgrade récupère le CLI, tale deploy l’applique. Omettre l’une laisse le déploiement sur l’ancienne version.
  4. Notes de migration manuelle (si pertinent) : si une breaking change demande une action opérateur au-delà de tale deploy, inclure une section ## Migration Guide avec étapes numérotées.
  5. Lien Full Changelog en bas : 
    **Full Changelog**: https://github.com/tale-project/tale/compare/v{previous}...v{new}

​
Règles de classification

  • Security : tout ce qui touche à l’authentification, session, stockage de secrets, crypto ou CVE de dépendance atteignable. Dans le doute, classer en security ET ouvrir un Security Advisory.
  • Model & Fournisseur : tout changement susceptible de modifier la sortie LLM pour la même entrée utilisateur — bumps de modèle, swaps de fournisseur, changements de prompts/templates dans les agents par défaut.
  • Breaking Changes : l’utilisateur ou l’opérateur doit faire quelque chose après la mise à jour. Si ça “fonctionne tout simplement”, ce n’est pas breaking.
  • Other : uniquement pour des changements notables qui ne rentrent nulle part ailleurs. Trivial (fautes de frappe, refactors internes, changements de tests seuls) est omis.

​
Exemple

# v1.6.0 — Usage analytics & multi-tenancy

This release adds time-based usage analytics, hardens multi-tenant org isolation,
and bumps the default reasoning model. No breaking changes.

## 🔒 Security

- Tighten org-scoping on governance policy queries (#1573)

## 🤖 Model & Provider

- Default reasoning model bumped from Opus 4.6 → Opus 4.7 (#1590)

## 🚀 Features

- Time-based usage analytics dashboard under `/metrics/usage` (#1574)
- Multi-org support: users can belong to multiple organizations (#1573)

## 🛠 Improvements

- Tabs underline variant adopted across settings surfaces (#1571)

## 🐛 Fixes

- Fix prompt library sidebar scroll on short viewports (#1572)

## Upgrade

Run `tale upgrade` to update the CLI, then `tale deploy` to apply the new version.

**Full Changelog**: https://github.com/tale-project/tale/compare/v1.5.2...v1.6.0

​
Lié

  • Processus de Security Advisory — quand ouvrir aussi un GitHub Security Advisory.
  • La slash-command /release du dépôt principal rédige les notes selon cette spec.
Last modified on April 20, 2026