LeSim commented 2 years ago

Les mises a jour de ds sur les instances hors dinum est difficile, en particulier sur le volet migration de données et identification des releases de sécu. Le cycle de déploiement des partenaires s'étale du mois par mois à l'année.

Cible :

Constituer d'une manière ou d'une autre un changelog plus accessible que notre page de release, qui permette aux mainteneurs d'avoir une vision sur les évols et des indications sur les étapes (versions) nécessaires pour mettre à jour.

Contrainte

De part la capacité limité de l'équipe core:

on privilégiera un maximum l'automatisation.
on écarte le sujet de version supporté pendant x mois avec report des mises à jour de sécurité

Dans le périmètre de cette issue :

aux migrations de données
changements sécu
changement de config
changements fonctionnels importants

Hors le périmètre de cette issue :

la gestion de code custom aux forks qui nécessite un travail à part et une charge de travail autrement plus conséquente

LeSim commented 2 years ago

Première idée :

on ramène dans le repo ds le bout code qui nous prépare nos releases notes en lisant nos commits, et de manière incrémentale on pourrait :

lui faire détecter des changements majeurs (migrations / task after_party / var d env)
lui faire écrire un change log
lui faire poser des questions (est-ce une version majeur, y'a-t-il un patch de sécu)

dzc34 commented 2 years ago

Je ne sais pas si c'est pertinent dans le cas de DS : nous utilisons beaucoup Conventional Commits qui permet entre autres de documenter directement dans les commits les "breaking change".

mfaure commented 2 years ago

Merci @LeSim pour cette issue ! Le tout premier besoin pour nous serait d'avoir toutes les infos de changelog en un seul et unique fichier, au hasard CHANGELOG ;)

Si vous outils de génération sont publiés, ça sera plus facile pour nous de proposer des contribs pour générer un CHANGELOG et comprendre ce que vous avez déjà construit.

Pour moi, les considérations de majeur / mineur / breaking change seront traités dans un second temps, d'abord je proposerai de travail sur le CHANGELOG en un seul et unique endroit.

Dan33l commented 2 years ago

Merci @lesim de nous donner d'occasion de parler du sujet.

A titre personnel, je fais partie du collectif Voxpupuli. Voxpupuli gère environs 200 modules Puppet. Chaque module dispose de sont fichier CHANGELOG. Nous nous servons de l'outil github_changelog_generator, alias GHCG. J'en parle pour le faire connaître, sans savoir s'il correspond aussi au besoin ici, mais c'est possible.

Le GHCG se base sur les titres des issues et des PR et sur les label mis sur ces objets. Chez Voxpupuli, nous sommes vigilants sur la formulation des titres des issues et des titres des PR. Nous gardons en tête la question suivante : "Est-ce que ce titre permet d'être clair dans un CHANGELOG ?" Et nous avons une tache rake pour homogénéiser le processus de release pour les plus de 100 mainteneurs de VP.

Voilà un cas d'organisation pour illustration. A disposition pour en parler, si cela peut aider.

kemenaran commented 2 years ago

Au sujet du changelog

Petite note : depuis quelques semaines, notre outil de génération de changelog ajoute déjà automatiquement aux releases notes des infos sur les migrations et moulinettes de données.

Cela dit, pour être utile, je pense qu'un changelog généré automatiquement doit pouvoir être éditorialisé par un humain avant publication. À voir quelle solution on peut trouver parmi toutes celles proposées qui permettent ça.

Autres sujets de mise à jour

Est-ce que ça serait utile aux personnes qui font des montées de version qu'on teste automatiquement que nos migrations passent toujours même quand on saute des versions ? (par exemple quelque chose comme ce qu'il y a dans Mastodon ?)