# Versions et changelog automatisés pour vos extensions avec release-please

> Conventional commits, génération automatique du changelog, mise à jour de l'en-tête et du readme à chaque release, sans y penser manuellement.

- Auteur : Clément Hadrot
- Publié le : 2022-10-05
- Mis à jour le : 2022-10-05
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/versions-changelog-automatises-release-please/

## L’essentiel

- Conventional commits comme unique source de vérité
- Pull request de release générée automatiquement
- En-tête et Stable tag mis à jour sans intervention manuelle

La désynchronisation entre le numéro de version de l'en-tête d'un plugin, celui du `readme.txt`, et le contenu réel du changelog est un classique agaçant : un développeur pressé publie une version 2.5.0 avec un changelog qui ne mentionne encore que les changements de la 2.4.0. `release-please`, l'outil créé par Google, automatise entièrement cette mécanique à partir d'une seule source de vérité : les messages de commit, à condition qu'ils suivent la convention *Conventional Commits*.

Ce tutoriel couvre la mise en place de release-please pour une extension WordPress, jusqu'à la génération automatique du changelog et la synchronisation des fichiers de version. La publication effective sur WordPress.org, qui suit une mécanique SVN différente, fait l'objet d'un autre article.

## Le principe des Conventional Commits

Cette convention impose un préfixe normalisé à chaque message de commit, qui indique la nature du changement :

```
feat: ajouter un filtre pour personnaliser le format de date
fix: corriger le double enregistrement du champ ACF
fix!: renommer la fonction publique mon_plugin_get_data()
docs: mettre à jour les exemples du readme
chore: mettre à jour les dépendances de développement
```

À partir de ces préfixes, release-please déduit automatiquement le type d'incrément de version sémantique à appliquer : `fix` incrémente le correctif (2.4.0 → 2.4.1), `feat` incrémente la version mineure (2.4.1 → 2.5.0), et un point d'exclamation après le type ou un pied de commit `BREAKING CHANGE:` incrémente la version majeure.

## Configurer release-please pour un plugin PHP

> L'essentiel à retenir : Conventional commits comme unique source de vérité ; Pull request de release générée automatiquement ; En-tête et Stable tag mis à jour sans intervention manuelle

Un fichier `release-please-config.json` à la racine indique quels fichiers contiennent un numéro de version à synchroniser :

```
{
  "packages": {
    ".": {
      "release-type": "php",
      "extra-files": [
        {
          "type": "generic",
          "path": "mon-plugin.php",
          "annotation": "Version: "
        },
        {
          "type": "generic",
          "path": "readme.txt",
          "annotation": "Stable tag: "
        }
      ]
    }
  }
}
```

Un second fichier, `.release-please-manifest.json`, garde la trace de la dernière version publiée pour chaque paquet :

```
{
  ".": "2.4.0"
}
```

## Le workflow GitHub Actions

```
name: Release Please
on:
  push:
    branches: [main]

permissions:
  contents: write
  pull-requests: write

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: googleapis/release-please-action@v4
        with:
          config-file: release-please-config.json
          manifest-file: .release-please-manifest.json
```

## Ce qui se passe concrètement à chaque push

À chaque fusion sur la branche principale, release-please analyse l'historique des commits depuis la dernière release, et maintient ouverte une pull request unique récapitulant le prochain changelog à venir :

1. Un commit `feat: ...` est mergé sur `main`
2. release-please détecte le changement et ouvre (ou met à jour) une pull request « chore(main): release 2.5.0 »
3. Cette pull request contient déjà le `CHANGELOG.md` généré, l'en-tête du plugin mis à jour et le `Stable tag` ajusté
4. Quand l'équipe merge cette pull request, release-please crée automatiquement le tag Git et la release GitHub correspondants

Cette pull request persistante est le cœur du système : elle s'actualise à chaque nouveau commit poussé sur `main`, et ne se ferme jamais toute seule — c'est son merge qui déclenche réellement la publication.

## Un extrait de changelog généré

```
## [2.5.0](https://github.com/mon-agence/mon-plugin/compare/v2.4.0...v2.5.0) (2022-10-05)

### Features

* ajouter un filtre pour personnaliser le format de date

### Bug Fixes

* corriger le double enregistrement du champ ACF
```

Ce changelog, généré sans intervention manuelle, respecte une structure lisible et cohérente d'une version à l'autre — un contraste net avec les changelogs rédigés à la dernière minute juste avant publication, souvent approximatifs sur les détails.

## Discipline requise côté équipe

> release-please ne pardonne pas l'à-peu-près : un message de commit vague comme « corrections diverses » n'apporte rien au changelog généré. La rigueur des messages de commit devient une exigence d'équipe, pas un détail de style.

Pour que l'automatisation reste fiable, quelques règles à faire respecter :

- Un hook de pré-commit ou de CI qui valide le format Conventional Commits avant d'accepter un commit
- Une description de commit suffisamment précise pour être lisible telle quelle dans un changelog public
- Un usage cohérent de `fix!:` ou `BREAKING CHANGE:` pour tout changement d'API publique du plugin

## En résumé

release-please transforme la gestion de version d'une extension WordPress d'une tâche manuelle sujette à l'oubli en un processus entièrement déductible de l'historique Git. Le seul investissement réel est humain : adopter et maintenir la discipline des Conventional Commits, condition sine qua non pour que l'automatisation produise un changelog réellement utile plutôt qu'une suite de messages génériques sans valeur informative.