Cycle de publication de Chaos Mesh

Traduction Bêta Non Officielle

Cette page a été traduite par PageTurner AI (bêta). Non approuvée officiellement par le projet. Vous avez trouvé une erreur ? Signaler un problème →

Ce document s'adresse aux développeurs et contributeurs de Chaos Mesh qui doivent créer une amélioration, un ticket ou une demande de tirage ciblant un jalon de publication spécifique.

Rôles

Contributeurs/Développeurs

Les contributeurs sont censés participer au cycle de publication sous les formes suivantes :

• participer aux discussions sur la collecte de nouvelles fonctionnalités/améliorations

• contribuer au code ou à la documentation de Chaos Mesh

• aider à élaguer les fonctionnalités si nécessaire

En tant que contributeur, les deux seules choses que tu dois garder à l'esprit sont :

• on peut te demander de terminer ton travail incomplet ou de le retirer de la branche de publication

• ta PR pourrait ne pas être fusionnée rapidement dans master pendant le "Gel du code"

Responsable de publication

Le terme "Responsables de publication" désigne les contributeurs de Chaos Mesh chargés de maintenir les branches de publication, d'étiqueter les versions, et de construire/empaqueter Chaos Mesh.

Les responsables de publication doivent :

• collecter les "nouvelles fonctionnalités/améliorations" via des tickets GitHub

• créer et maintenir le jalon GitHub vX.Y.0

• planifier et animer les réunions nécessaires

• maintenir la documentation de suivi pour la prochaine publication

• contacter les contributeurs pour demander de l'aide pour terminer/retirer les fonctionnalités/docs inachevées, ou les retirer toi-même si la communication est perdue

• créer la branche de publication

• rédiger les Notes de publication pour la version mineure

• publier les versions alpha, bêta et mineures

• enrichir continuellement la documentation liée aux publications

Comment devenir responsable de publication ?

Les mainteneurs et committers de Chaos Mesh proposent de nouveaux responsables en première semaine du cycle, via le canal Slack #chaos-mesh-maintainers. Ils sont sélectionnés si moins de la moitié s'oppose. L'annonce finale est publiée sur le site documentaire et le canal #project-chaos-mesh.

Schéma de versionnage et calendrier

• Chaos Mesh publie une version mineure vX.Y.0 toutes les 8 semaines

• Chaos Mesh publie une version préliminaire (vX.Y.0.alpha/beta-W, W≥0) au moins toutes les 2 semaines

• Chaos Mesh publie des correctifs (vX.Y.Z, Z>0) selon les besoins

Phases de publication

Un cycle de publication comporte 3 phases :

• Développement normal (Semaines 1-5)

• Gel du code (Semaines 6-7)

• Semaine de publication (Semaine 8)

Développement normal

Activités pendant le "Développement normal" :

• sélection des nouveaux responsables de publication

• collecte des "nouvelles fonctionnalités/améliorations" pour la prochaine publication

• création du jalon vX.Y.0 s'il n'existe pas

• codage et documentation

• publication des versions alpha toutes les 2 semaines

Gel du code

Activités pendant le "Gel du code" :

• blocage de la fusion des PR non pertinentes

• examen des "nouvelles fonctionnalités/améliorations" incluses dans la prochaine version

  • finaliser ou supprimer les fonctionnalités non terminées
  • les documents sont prêts, avec au moins une issue ouverte sur chaos-mesh/website

• création de la branche release-X.Y

• publication des versions bêta

• préparation des notes de version

• création du jalon vX.Y+1.0

• fusion des corrections de bogues si nécessaire

• documentation relative à la nouvelle version

La phase de "Gel du code" démarre à la semaine 6 et s'achève lors de la création de la branche release-X.Y.

Pendant le "Gel du code", les PR non liées à la prochaine version mineure ne peuvent pas être fusionnées dans master. Seules les PR concernant la prochaine version sont fusionnables dans la branche principale.

Les responsables de version contactent les contributeurs pour leur demander de finaliser ou supprimer les fonctionnalités non terminées. Ils peuvent les supprimer eux-mêmes en cas de perte de contact avec les contributeurs.

Une fois les fonctionnalités non finalisées terminées ou marquées "à supprimer", le responsable de version crée la branche release-X.Y. Le processus de fusion des PR reprend normalement.

Après suppression des fonctionnalités non terminées, le responsable de version publie la première version bêta. Par la suite, seules les corrections de bogues seront cherry-pickées dans la branche de version. D'autres versions bêta peuvent être publiées en cas de mises à jour.

Le responsable de version doit commencer à préparer les notes de version après la publication bêta.

Semaine de publication

Événements durant la "semaine de publication" :

• fusion des corrections d'urgence de bogues ou vulnérabilités si nécessaire

• publication des artefacts de la version mineure (charts Helm, images conteneur, etc.)

• publication de la documentation de la version mineure

Le responsable de version publie la version vX.Y.0 cette semaine.