en tant que membre de l’équipe LinuxFr.org : le code en lui-même n’est pas versionné (autrement qu’être une succession de commits datés), ils sont annoncés dans les rétrospectives de la quinzaine mais sans effort particulier de vulgarisation, et parfois une dépêche vient décrire les nouveautés (il y en a une en rédaction par exemple).
en tant que développeur, sur du code partagé mis à la disposition d’autres personnes (par exemple des rôles ansible communautaires) : quasi chaque commit donne lieu à une version, et donc je décris à chaque fois le changement (et l’étiquette x.y.z sur le commit permet aussi de savoir à quel point on a cassé la rétrocompatibilité). Mais je ne m’astreins pas à avoir en plus un fichier Changelog dans le dépôt.
en tant que admin sys, avant de faire des mises à jour liées à du fonctionnel (ie. pas juste des mises à jour de sécurité, confiées aux équipes de la distribution par exemple), alors je parcours les notes de version notamment pour voir des ruptures de compatibilité éventuelles, ou des annonces de fonctions obsolètes ou en voie de l’être, ou des changements de configuration, ou même des nouvelles fonctionnalités qui pourraient m’intéresser. Souvent une lecture rapide en diagonale, parce que toute façon il est peu probable que je comprenne chaque ligne individuellement, sauf à connaître sur le bout des doigts le logiciel en question, et encore...
en tant que simple utilisateur : ça dépend, je lis les notes de versions pour les montées de distribution Debian par exemple, j’essaie de lire les notes de versions de chaque application sur mobile (mais souvent c’est plus que sommaire « on a corrigé des trucs » et « on a amélioré les perfs ») mais c’est tellement fréquent...
# Retours
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Changelog, pour quoi, pour quoi ?. Évalué à 10.