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
boutons-danger
dev-sortable
dev/autoloader
dev/instituer_ergo
dev_infos_image
fix/valider_url_distante
fix_modifier_login
issue_4101
issue_4277_bis
issue_4678
issue_4705
issue_4717
issue_4946
issue_5032_ini_set
issue_5056_composer_road
issue_5242
issue_deprecated_null_sql_quote
master
spip-1.8.3b
spip-1.9.1i
spip-1.9.2f
spip-1.9.2g
spip-1.9.2h
spip-1.9.2i
spip-1.9.2j
spip-1.9.2k
spip-1.9.2m
spip-1.9.2n
spip-1.9.2o
spip-1.9.2p
spip-2-stable
spip-2.0.0
spip-2.0.1
spip-2.0.10
spip-2.0.11
spip-2.0.12
spip-2.0.13
spip-2.0.14
spip-2.0.15
spip-2.0.16
spip-2.0.17
spip-2.0.18
spip-2.0.19
spip-2.0.2
spip-2.0.20
spip-2.0.21
spip-2.0.22
spip-2.0.23
spip-2.0.24
spip-2.0.25
spip-2.0.26
spip-2.0.3
spip-2.0.5
spip-2.0.6
spip-2.0.7
spip-2.0.8
spip-2.0.9
spip-2.1.0
spip-2.1.1
spip-2.1.10
spip-2.1.11
spip-2.1.12
spip-2.1.13
spip-2.1.14
spip-2.1.15
spip-2.1.16
spip-2.1.17
spip-2.1.18
spip-2.1.19
spip-2.1.2
spip-2.1.20
spip-2.1.21
spip-2.1.22
spip-2.1.23
spip-2.1.24
spip-2.1.25
spip-2.1.26
spip-2.1.27
spip-2.1.28
spip-2.1.29
spip-2.1.3
spip-2.1.30
spip-2.1.4
spip-2.1.5
spip-2.1.6
spip-2.1.7
spip-2.1.8
spip-2.1.9
spip-3.0.0
spip-3.0.0-alpha1
spip-3.0.0-beta
spip-3.0.0-beta2
spip-3.0.0-rc
spip-3.0.1
spip-3.0.10
spip-3.0.11
spip-3.0.12
spip-3.0.13
spip-3.0.14
spip-3.0.15
spip-3.0.16
spip-3.0.17
spip-3.0.18
spip-3.0.19
spip-3.0.2
spip-3.0.20
spip-3.0.21
spip-3.0.22
spip-3.0.23
spip-3.0.24
spip-3.0.25
spip-3.0.26
spip-3.0.27
spip-3.0.28
spip-3.0.3
spip-3.0.4
spip-3.0.5
spip-3.0.6
spip-3.0.7
spip-3.0.8
spip-3.0.9
spip-3.1.0
spip-3.1.0-alpha
spip-3.1.0-beta
spip-3.1.0-rc
spip-3.1.0-rc2
spip-3.1.0-rc3
spip-3.1.1
spip-3.1.10
spip-3.1.2
spip-3.1.3
spip-3.1.4
spip-3.1.5
spip-3.1.6
spip-3.1.7
spip-3.1.8
spip-3.1.9
spip-3.2-alpha-1
spip-3.2.0
spip-3.2.0-beta
spip-3.2.0beta2
spip-3.2.0beta3
spip-3.2.1
spip-3.2.2
spip-3.2.3
spip-3.2.4
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.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.2
v4.0.3
v4.0.4
v4.0.5
v4.0.6
v4.0.7
v4.1.0
v4.1.0-alpha
v4.1.0-beta
v4.1.0-rc
v4.1.1
v4.1.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
5 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