Faciliter les modifications des fichiers Changelog #5524

Pour faire suite à #5208

https://packagist.org/packages/automattic/jetpack-changelogger qui permet de générer des changelogs au format keepachangelog
https://packagist.org/packages/markwalet/laravel-changelog permet plus de choses, mais semble nécessiter d'être dans un projet laravel pour fonctionner, dommage :\
https://packagist.org/packages/churchtools/changelogger semble pas mal aussi, stocke les entrées dans des fichiers yaml (mais pas compatible avec PHP 8.2)

semble nécessiter d'être dans un projet laravel pour fonctionner, dommage :\

Non, ça ne semble pas, ça fournit effecivement une commande pour artisan, disponible dans toutes les instances laravel, un peu comme bin/console dans une appli symfony. D'ailleurs c'est basé sur le même composant 😉

À quand un polatouche dans SPIP ? 👼

à quand, à quand ? you mean ce ptit projet qui existe depuis 10 ans ? 😱
(et qui pourrait parfaitement être fourni dans la dist, en séparant les rares commandes qui doivent absolument pouvoir être lancée en dehors d'une instance déjà téléchargée)
https://git.spip.net/spip-contrib-outils/spip-cli

@JamesRezo ça m'intéresse, il faut donc que je trouve comment utiliser artisant en dehors d'un projet laravel.

non non artisan c’est fait pour tourner avec Laravel !

Ha une piste https://github.com/matthewbdaly/artisan-standalone => non concluante :\

à quand, à quand ? you mean ce ptit projet qui existe depuis 10 ans ? 😱

Je ne "meanait" rien mais tu auras, je pense, plus de facilité à le faire depuis l'intoduction de composer et de l'autoloading dans spip : #5056

en séparant les rares commandes qui doivent absolument pouvoir être lancée en dehors d'une instance déjà téléchargée

Je n'ai pas d'idée précise sur les commandes à exécuter en dehors d'un SPIP, mais je suppose qu'en partie, c'est pour faire des installation et des mises à jour. J'espère qu'on arrivera un jour à gérer ces cas-là avec composer directement. S'il y en a d'autres, j'y jetterai un oeil.

Et en attendant, ce serait intéressant de voir si jetpack-changelogger est intégrable dans spip-cli, pourquoi pas ? tu t'y colles @rastapopoulos ?

dsl point le temps du tout de spiper du code (ou de coder du spip) en ces temps trop chargés (d'autant plus pour un outil dont je ne sais pas encore trop ce qu'il fait, et encore moins le temps d'étudier ça)

mais d'après ses require, ça semble faisable (au pire en mappant telle quelle une commande "spip truc" qui appelle une commande fournit par ce projet, ya une fonction de Console pour appeler une Command depuis une autre Command)

J'ai testé la première piste, voici un exemple de changelog généré :

# Changelog

## 4.3.1 - 2023-03-13
### Security
- #5656 un fix de secu

### Changed
- #5657 refactore d'une foncion

### Fixed
- #3434 un autre petit bug

## 4.3.0 - 2023-03-13
### Fixed
- #3232 un petit bug

Exemple de contenu pour le fix secu dans changelog/issue_5656

Significance: patch
Type: security

#5656 un fix de secu

Ça me semble pas mal, on peut générer le fichier de changelog en cli ou à la main sans trop de prise de tête et le fait de nommer les fichier comme la branche liée permet de s'y retrouver facilement.

Seul truc qui manque par rapport aux autre outils, la possibilité d'afficher le changelog des items temporaires de /changelog en attente d'intégration au changelog du projet.

Edit :

On peut passer unreleased en date vendor/bin/changelogger write --release-date unreleased ce qui donne ceci :

## 4.3.1 - unreleased
### Security
- #5656 un fix de secu

### Changed
- #5657 refactore d'une foncion

### Fixed
- #3434 un autre petit bug

## 4.3.0 - 2023-03-13
### Fixed
- #3232 un petit bug

Truc cool, on peut compléter le changelog au fil de l'eau avec vendor/bin/changelogger write --release-date unreleased --amend.

Il me semble qu’on pouvait pas lui faire écrire Unreleased avec les éléments ? Qu’il fallait forcément publier une version pour ça ?

Il me semble qu’on pouvait pas lui faire écrire Unreleased avec les éléments ? Qu’il fallait forcément publier une version pour ça ?

Je confirme, c'est pour ça que laravel-changelog me semblait intéressant avec ces commandes dédiées à ça :

php artisan changelog:unreleased (Show a list of unreleased changes)
php artisan changelog:current (Show a list of unreleased changes for your current branch)

Par contre, je découvre que jetpack-changelogger permet des trucs sympas cf vendor/bin/changelogger write --help :

--deduplicate=DEDUPLICATE            Deduplicate new changes against the last N versions. Set -1 to disable deduplication entirely. [default: 1]

Le seul truc qui me chagrine c'est que le champ Significance est obligatoire, j'ai testé sans et ça ne valide pas, mais bon il tout de même l'intérêt de permettre de déterminer la version à publier en fonction des types de patchs.

Je viens de tester le 3e outil, il a l'avantage de fournir une commande qui liste les entrées pas encore intégrées au changelog, exemple :

bb@tybook:~/sites/trunk/test$ php7.4 vendor/bin/changelogger new

 Type of change:
  [0] New feature
  [1] Bug fix
  [2] Hotfix
  [3] Feature change
  [4] New deprecation
  [5] Feature removal
  [6] Security fix
  [7] Performance improvement
  [8] Other
  [9] No Changelog
 > 1

 Your changelog:
 > #123 alors c'est mieux ?

Saving Changelog changelogs/unreleased/2023-03-17-041444-master.yml: ✔
Changelog generated:
title: '#123 alors c''est mieux ?'
type: fixed
author: ''
group: ''

Contenu du fichier yaml généré :

bb@tybook:~/sites/trunk/test$ cat changelogs/unreleased/2023-03-17-041444-master.yml 
title: '#123 alors c''est mieux ?'
type: fixed
author: ''
group: ''

Affichage des entrées par encore intégrées :

bb@tybook:~/sites/trunk/test$ php7.4 vendor/bin/changelogger show
+-----+-------+--------------------------+--------+
| No. | Type  | Log                      | Author |
+-----+-------+--------------------------+--------+
| 1   | fixed | #123 alors c'est mieux ? |        |
+-----+-------+--------------------------+--------+

Par contre, l'outil ne fonctionne que avec PHP 7.4 => 8.0.