No Branch/Tag Specified
1.8
1.9.1
1.9.2
2.0
2.1
3.0
3.1
3.2
4.0
4.1
4.2
boutons-danger
coquille_doc
debug_ecrire_fichier
dev-sortable
dev/autoloader
dev/hasard_fixe
dev/instituer_ergo
dev/issue_4626_menu_squelettes
dev/issue_5496_intro_ligne_null
dev_infos_image
fix/valider_url_distante
fix_issue_5454
fix_modifier_login
issue_4101
issue_4678
issue_4705
issue_4717
issue_4836
issue_4946
issue_5095
issue_5344
issue_5427_bis
master
refactor_extraire_balises
remove_no_image_filtrer
trigger_deprecated_42
v1.8.3+b
v1.9.1+i
v1.9.2+f
v1.9.2+g
v1.9.2+h
v1.9.2+i
v1.9.2+j
v1.9.2+k
v1.9.2+m
v1.9.2+n
v1.9.2+o
v1.9.2+p
v2.0.0
v2.0.1
v2.0.10
v2.0.11
v2.0.12
v2.0.13
v2.0.14
v2.0.15
v2.0.16
v2.0.17
v2.0.18
v2.0.19
v2.0.2
v2.0.20
v2.0.21
v2.0.22
v2.0.23
v2.0.24
v2.0.25
v2.0.26
v2.0.3
v2.0.5
v2.0.6
v2.0.7
v2.0.8
v2.0.9
v2.1.0
v2.1.1
v2.1.10
v2.1.11
v2.1.12
v2.1.13
v2.1.14
v2.1.15
v2.1.16
v2.1.17
v2.1.18
v2.1.19
v2.1.2
v2.1.20
v2.1.21
v2.1.22
v2.1.23
v2.1.24
v2.1.25
v2.1.26
v2.1.27
v2.1.28
v2.1.29
v2.1.3
v2.1.30
v2.1.4
v2.1.5
v2.1.6
v2.1.7
v2.1.8
v2.1.9
v3.0.0
v3.0.0-alpha.1
v3.0.0-beta
v3.0.0-beta.2
v3.0.0-rc
v3.0.1
v3.0.10
v3.0.11
v3.0.12
v3.0.13
v3.0.14
v3.0.15
v3.0.16
v3.0.17
v3.0.18
v3.0.19
v3.0.2
v3.0.20
v3.0.21
v3.0.22
v3.0.23
v3.0.24
v3.0.25
v3.0.26
v3.0.27
v3.0.28
v3.0.3
v3.0.4
v3.0.5
v3.0.6
v3.0.7
v3.0.8
v3.0.9
v3.1.0
v3.1.0-alpha
v3.1.0-beta
v3.1.0-rc
v3.1.0-rc.2
v3.1.0-rc.3
v3.1.1
v3.1.10
v3.1.11
v3.1.12
v3.1.13
v3.1.14
v3.1.15
v3.1.2
v3.1.3
v3.1.4
v3.1.5
v3.1.6
v3.1.7
v3.1.8
v3.1.9
v3.2-alpha.1
v3.2.0
v3.2.0-alpha.1
v3.2.0-beta
v3.2.0-beta.2
v3.2.0-beta.3
v3.2.1
v3.2.10
v3.2.11
v3.2.12
v3.2.13
v3.2.14
v3.2.15
v3.2.16
v3.2.17
v3.2.18
v3.2.19
v3.2.2
v3.2.3
v3.2.4
v3.2.5
v3.2.6
v3.2.7
v3.2.8
v3.2.9
v4.0.0
v4.0.0-alpha
v4.0.0-beta
v4.0.1
v4.0.10
v4.0.11
v4.0.2
v4.0.3
v4.0.4
v4.0.5
v4.0.6
v4.0.7
v4.0.8
v4.0.9
v4.1.0
v4.1.0-alpha
v4.1.0-beta
v4.1.0-rc
v4.1.1
v4.1.2
v4.1.3
v4.1.4
v4.1.5
v4.1.6
v4.1.7
v4.1.8
v4.1.9
v4.2.0
v4.2.0-alpha
v4.2.0-alpha2
v4.2.1
v4.2.2
Labels
Amélioration, nouvelle fonctionnalité APIs authentification base de données bug
Ca ne fonctionne pas code généré compilo css divers documentation doublon
Ce ticket est un doublon ergonomie espace privé filtres et balises formulaires Inscription installation invalide
Ticket invalide javascript langues LDAP plugin PostgreSQL refusé
Ignoré, c'est comme Ca... sécurité traduction
Apply labels
Clear labels
accessibilité
amélioration
Amélioration, nouvelle fonctionnalité APIs authentification base de données bug
Ca ne fonctionne pas code généré compilo css divers documentation doublon
Ce ticket est un doublon ergonomie espace privé filtres et balises formulaires Inscription installation invalide
Ticket invalide javascript langues LDAP plugin PostgreSQL refusé
Ignoré, c'est comme Ca... sécurité traduction
No Label
accessibilité
amélioration
APIs
authentification
base de données
bug
code généré
compilo
css
divers
documentation
doublon
ergonomie
espace privé
filtres et balises
formulaires
Inscription
installation
invalide
javascript
langues
LDAP
plugin
PostgreSQL
refusé
sécurité
traduction
Milestone
Set milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Assign users
Clear assignees
No Assignees
6 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.
No due date set.
Dependencies
This issue currently doesn't have any dependencies.
Reference in new issue
There is no content yet.
Delete Branch '%!s(MISSING)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
No
Yes
Nous avons introduits un
CHANGELOG.md
dans SPIP et ses plugins-dist en suivant https://keepachangelog.com/en/1.0.0/ . Cf #5042 et #5121Actuellement
On voit que déjà il y a quelques problématiques (sur les reports, sur master après release) pour gérer le CHANGELOG.
Améliorer les logs de commits
Si on veut pouvoir (re) générer automatiquement un Changelog lors d’une release (plutôt que de le traiter à la main — Keep a Changelog suggère de mettre que les éléments pertinents pourtant), il faut que les logs de commits soient facilement identifiables pour indiquer si cet élément est important à prendre en compte, et à quel endroit dans le changelog.
Mais même, rien que pour la rigeur et la relecture, des bons logs, c’est bien :)
Il existe "Conventional Commits" https://www.conventionalcommits.org/fr/v1.0.0/ pour ça.
Cette nomenclature fonctionne sur la base d’un titre qui identifie le type de commit (
fix:
,feat:
par défaut), où chaque projet définit un peu ses types.Un article en parle là et propose une liste qui peut se coupler avec Keep a Changelog en partie
https://medium.com/neudesic-innovation/conventional-commits-a-better-way-78d6785c2e08
Remarques
Ce qui est ennuyant me semble t’il est que Conventional Commits place les références extérieures (N° de tickets) dans le footer du message de commit, ce qui fait qu’on ne les voit pas directement sur un
git log --oneline
ou équivalentsQuestions
Est-ce qu’on peut se dire qu’on essaie d’écrire les logs de commits en suivant cette nomenclature ?
Si on a une base de logs comme ça ça pourra permettre de voir si on peut les utiliser ensuite pour générer un changelog pertinent avec des outils adaptés, tel que https://github.com/marcocesarato/php-conventional-changelog
Est-ce qu’on peut se définir éventuellement une liste de
scopes
? À quel endroit du logiciel on intervient (mis entre parenthèses après le type) tel quefix(api):
Super, voilà un début de conf pour
php-conventional-changelog
pour suivre ces recommandation :Dans mon cas, j'ai opté pour sec au lieu de security et deprec au lieu de deprecate pour faire plus court, mais on peut s'aligner sur ce que mentionne l'article que tu cites.
En reprenant quelques logs de commits de la 4.1, ça donne le source qui suit visible ici https://rentry.co/2adnu
Je proposerais bien une version plus court pour remove => rem ou del.
Plutôt partisan, après je me posais la question de la compatibilité avec d'autres automatismes attendus, notamment ce qui est reconnu par toutes les forges (Gitea et autres). Non seulement eux mettent la référence à la fin, mais même si on mettait dans la parenthèse, ça ne correspondrait pas aux
fix #123
reconnus qui permet d'interragir auto sur des tickets depuis les logs.Après au pire on le met en double, un peu dommage mais ça marcherait…
Pas besoin de le mettre en double, car comme je le disais sur IRC, l'écriture
fix(#XXX):
n'est pas "valide" et n'est pas prise en charge par l'outilphp-conventional-changelog
. Un log "correct" serait de la forme :bé oui ya bien deux fois le mot-clé Fix, c'est ce que je disais :)
On peut pas mettre la ref au même endroit que le mot-clé du début quoi, donc faut le remettre ailleurs dans le log (sans les : je crois pour les forges, ou bien ça gère plusieurs écritures mais peu importe ça). Donc bon oui c'est pas très grave, on le met deux fois
Oui ça fait deux fois Fix, mais le type du commit ne sert pas à ça, et quand c'est un commit qui apporte un changement par exemple, ya plus doublon :p
PS :
Fix:
est pris en charge par github d'après l'article cité par @marcimat donc je pense que gitea en fait de même (enfin j'espère ^^).Ceci étant dit je trouve ennuyant de pas voir le ticket directement dans un
git lg
(mais c’est peut être juste moi).Même si
feat
est un raccourci, commeperf
je suis plutôt pour ne pas s’éloigner de ce que proposent «les autres» sur les différents types, et donc si on doit pouvoir indiquer Deprecated, Removed et Security, alors autant prendre ce que propose l’article de Medium (mais c’est le seul endroit où ça en cause), par exemple chez Angular (https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit), ça irait semble t’il dansrefactor
oufix
pour ces cas.Notons que Gitlab utilise un autre trick https://docs.gitlab.com/ee/development/changelog.html en ne reportant dans le changelog que les commits qui ont un tag
Changelog: <type>
dans le footerTrès bonne idée.
Du moment qu'il y a une recette facile à suivre et bien documentée, on suivra :)
Ma seule remarque, comme suggéré par @marcimat, si on peut éviter les petites exceptions "à la spip" et pas trop s'éloigner de ce que font «les autres», ça sera plus facile à retenir.
Ça discute les motclés retenus et leur traitement, mais quelle est l'interface pour le dev = quelle apparence au final doit prendre un log de commit ?
Un exemple rendrait ça plus clair.
"Au hasard" parmi cette liste https://git.spip.net/spip/spip/commits/branch/master :
fd36a8dacb
2f20ecd7a3
Tiens là https://github.com/fteem/git-semantic-commits je vois que y a aussi "localize:" ça pourrait être bien pour salvatore aussi, et certains de nos commits…
Ha oui bonne idée, mais pour faire plus court
i18n
serait peut-être plus adapté ?i18n
oul10n
?/mode troll on
Ha mais oui l10n carrément !
=> https://fr.wikipedia.org/wiki/Internationalisation_et_localisation
Pour mémoire, je découvre https://scriv.readthedocs.io/en/latest/philosophy.html
L'outil est en python, donc pas forcément intéressant pour nous, mais le principe l'est : chaque entrée de changelog est stockée dans un fichier d'un répertoire dédié, et on peut lancer la génération du changlog à partir de ces fichiers. Ça permet d'éviter les soucis de conflit sur le changelog.
J'ai trouvé des outils en php qui fonctionnent sur le même principe :
En regardant comment fonctionne https://packagist.org/packages/automattic/jetpack-changelogger on a découvert avec @b_b qu’on n’écrivait pas totalement comme il fallait les changelog de SPIP suivant Keep a Changelog.
Effectivement les titres sont de ce type
## [x.y.z] - YYYY-MM-DD
Mais les crochets, en fait renvoient à une note en markdown, et je n’avais pas fait attention (je ne connaissais pas cette écriture markdown en fait). En pied de fichier, il devrait y avoir
[x.y.z]: une URL vers le diff ou le tag
Ou alors on devrait écrire (sans lien)
## x.y.z - YYYY-MM-DD
Je pense qu'on peut se simplifier la vie et se passer du lien.
En lien avec https://discuter.spip.net/t/proposition-devolution-des-regles-de-contribution/161362/6
Maintenant que c'est dans nos règles de contribution https://www.spip.net/fr_article825.html#Regles-de-contribution on peut fermer le ticket ?
À moins qu'on le garde sous le coude pour avancer sur la question de jetpack-changelogger et cie ?
j'aurais tendance à en faire un autre, pour avoir un historique clean.
La suite par là #5524 et on ferme ici.