Mainteneur de version OpenClaw

Que fait Mainteneur de version OpenClaw ?

À utiliser pour une opération de version, pas pour du développement ordinaire ou une mutation d'avis. Lisez docs/reference/RELEASING.md pour la politique actuelle. Chargez $release-private lorsqu'il est disponible avant de résoudre les localisateurs d'identifiants privés ou la topologie des hôtes ; les opérations d'identifiants utilisent $one-password.

Choisir l'opération

Lisez uniquement les références nécessaires pour la phase sélectionnée :

• Préparation ou publication régulière bêta/stable : version régulière, qui achemine la préparation et les preuves spécifiques à la phase. Si la demande ne spécifie pas stable/complete, par défaut prendre bêta ; l'autorisation bêta n'autorise pas une promotion stable ultérieure.
• Découverte de rétroportage : inventaire des candidats. Pour la version étendue-stable, lisez aussi préparation des rétroportages ; les changements SDK/config nécessitent un avertissement visible sur le risque de maintenance et une décision du mainteneur.
• Publication de la passerelle étendue-stable .33+ : publication étendue-stable. Utilisez l'éditeur partagé avec les entrées étendues-stables ; sa version GitHub Release non-Latest porte des preuves sans publication native-app ou ClawHub.
• Sélection de validation ou preuve échouée : validation et confiance, avec $release-openclaw-ci pour l'exécution des workflows et les manifests immuables.
• Publication interrompue ou promotion de registre : récupération de publication.
• Actifs natifs : publication de plateforme, avec $release-openclaw-mac pour les opérations macOS.
• Synchronisation post-publication stable et transfert de déploiement SHA exact : clôture principale.
• Notes de version : $openclaw-changelog-update, y compris sa route distincte de miroir de documentation post-version approuvée. La génération initiale de version conserve son format existant ; la publication de documentation ne s'exécute pas automatiquement pendant la version. Annonces demandées : $release-openclaw-announcement pour Discord, $release-tweets pour X. Les annonces ne bloquent jamais la publication et nécessitent une autorisation de publication explicite.
• Vérification des artefacts publiés : $verify-release. Opérations GHSA : $openclaw-ghsa-maintainer uniquement avec autorisation explicite de workflow de sécurité.

Limites partagées de version

Chaque voie de validation sélectionnée doit réussir : Node Windows et macOS et autres tâches CI normales, test d'installation fumée, voies de survie, update-first-hop-compat*, qualification pack/npm, intégrité des paquets, et vérifications de la passerelle Linux/Windows/macOS, y compris les vérifications d'installation/mise à niveau packagées Windows dans les vérifications de version. Une exécution annulée bloque toujours. Conservez les premiers échecs et classez chacun d'eux comme ci-dessous avant la récupération. La publication stable nécessite des preuves stables/complete, un trempage, et des performances bloquantes. Les preuves de profil bêta ne peuvent pas autoriser la publication stable. Aucune dérogation de voie ou de trempage ne peut contourner ces exigences. Les neuf combinaisons d'installation/mise à niveau de la passerelle sur Linux, Windows et macOS sont requises pour la qualification de tous les groupes. Conservez l'identité, la provenance, les preuves complètes et les approbations de publication existantes.

Chaque test échoué reçoit une décision explicite du responsable, véritable bloqueur de version ou instable, enregistrée dans le transfert avec ses preuves : le même SHA réussissant ailleurs ou lors d'une réexécution, aucune relation avec le delta de version, une signature du runner ou de l'infrastructure, un historique de la même instabilité de cas, ou un bug produit préexistant qui n'est pas une régression (par exemple le bug "Assigner à…" du 2026.9.6). Un véritable bloqueur est une régression dans les octets ou le comportement livré, ou un défaut de mise à jour/installation/publication ; corrigez-le sur la branche de version. Réexécutez un instable sur le même SHA de version avec au plus deux réexécutions enregistrées par défaut, et déposez un problème ou une PR de correction en parallèle sur main avec les preuves. Ne recréez jamais, ne changez pas d'outillage, et ne démarrez pas une nouvelle FRV pour un instable. Un instable qui reste rouge bloque la publication. Les échecs uniquement sur main et les échecs d'infrastructure (pannes de runner, jobs fantômes GitHub, décharge du runner hébergé) comptent comme des instables pour la version.

Les avis de dépendance ne retardent jamais une version. Un avis nouvellement publié n'est jamais une raison de recréer, changer d'outillage ou réexécuter la validation. Enregistrez-le dans les preuves de version et le transfert, puis déposez ou mettez en file d'attente le bump de dépendance sur main comme suivi normal après publication. Seule une découverte de malware connu arrête la publication. Les preuves de dépendance de version et la CI déclenchée par la version l'appliquent.

La santé CI de main ne bloque jamais une version. La validation et la publication s'exécutent à partir de la branche de version plus l'outillage épinglé, donc un main rouge n'est pas une raison d'attendre, recréer ou faire une pause. Lorsque la version a besoin d'une correction d'outillage de version sur main (les SHA d'outillage doivent être des commits main de confiance), les échecs main que la correction ne cause pas ne doivent pas empêcher cet atterrissage : prouvez sur un checkout main propre que l'échec existe déjà là, enregistrez-le dans le corps de la PR, et fusionnez. Pendant une version active, une fusion admin est autorisée pour une PR d'outillage de version exactement dans cette situation. Un main rouge est toujours corrigé, en parallèle par une voie séparée, jamais sur le chemin critique de la version.

Les objectifs opérationnels sont d'environ 20 minutes pour sceller la validation et la publication en une heure, sans garanties mesurées. Les enfants sources seulement démarrent en même temps que les producteurs d'artefacts ; les consommateurs candidats démarrent dès que le candidat est prêt. Les enfants verts scellés indépendamment peuvent être réutilisés pour la même cible et les mêmes entrées exactes même si leur parent a échoué, a été annulé, ou reste actif ; vérifiez leur identité de qualification admise originale (ou SHA de workflow historique de confiance main) et la tentative actuelle. Le manifeste scellé fournit le digest des preuves SDK et les décisions de publication npm ; il ne reconnaît jamais les changements API SDK, donc fournissez plugin_sdk_api_acknowledgement chaque fois que le rapport SDK contient des changements. L'éditeur ne peut pas accepter de preuves de validation dérogées. Les entrées explicites de l'éditeur sélectionnent la portée de publication ; l'assistant candidat valide toujours son acknowledgement SDK explicite si nécessaire.

L'approbation explicite est requise pour les changements de version et la publication irréversible. Une demande pour créer, publier ou compléter une version nommée est valable à travers sa publication et vérification validées ; ne demandez pas à nouveau sauf si l'identité, le canal, la portée ou le risque matériel change. L'autorité de livraison pour le code ordinaire n'est pas l'autorité de version.

L'approbation explicite d'un opérateur pour faire tout ce qui est nécessaire pour préparer une version nommée est une autorité permanente pour les décisions et réparations de préparation nécessaires. Appliquez-la aux corrections de candidat et d'outillage, à la conception de mise à niveau/migration, aux alignements de test ou d'inventaire de sécurité révisés, aux preuves isolées, aux commits, aux poussées, et à la récupération de validation. Enregistrez la décision, ses preuves, et le contrat de support sélectionné ; ne demandez pas à nouveau simplement parce qu'un travail déjà approuvé atteint une étape d'implémentation ou de vérification. Continuez le travail indépendant tout en résolvant un bloqueur. Cette autorité ne permet pas de cacher des défauts, d'abaisser une porte pour fabriquer un succès, des changements destructeurs à l'état de l'opérateur, un travail sans rapport, ou une publication. Une demande de seulement préparation nécessite toujours une instruction de publication séparée avant de libérer des artefacts ou une version de pont.

Gardez un enregistrement d'état compact en utilisant le modèle de transfert : objectif effectif, version/tag/branche, SHA de Cut/Code/Release, identités C/Q/P, exécution et tentative parent actives, artefacts enfants réussis, changements approuvés, phase et action suivante. La direction la plus récente de l'opérateur remplace la portée remplacée. Les preuves complètes restent complètes jusqu'à ce qu'un changement nommé les invalide.

Pour les versions régulières, préparez des notes complètes avant de geler le SHA Code si possible. Si ces notes sont finales, le SHA Code et le SHA Release sont le même commit : une seule qualification complète fraîche réussie peut fournir les deux rôles et leurs octets de publication exacts. Ne créez pas un autre commit ou exécution uniquement pour séparer les étiquettes. Si les notes changent après la qualification, un descendant dont le delta complet inclut CHANGELOG/<version>.md (version bêta exacte ou base stable) et seulement cette entrée, son enregistrement correspondant, et l'index racine peut utiliser split-changelog-release-v1 pour réutiliser les preuves de produit tout en qualifiant de nouveaux octets de publication. Tout autre delta source, renommage, ou suppression revient à la boucle SHA Code. Les reçus historiques racine seulement conservent changelog-only-release-v1. La nouvelle qualification gèle Q=C : toute la fermeture du workflow de qualification appartient au candidat. Gardez P (admission, vérificateur, et éditeur) indépendant et séparé. Une réparation de harnais Q nécessite un nouveau C/Q et des preuves nouvellement liées ; les réparations P uniquement ou d'infrastructure peuvent préserver le candidat. Les contrats de qualification manquants nécessitent un rétroportage délibéré, jamais un repli futur-main.

Une fois qu'un candidat est créé, sa base est la décision de l'opérateur. Ne recréez jamais (re-baser le candidat sur un main plus récent) à moins que Peter ne le demande explicitement pour cette version. Sans demander, cherry-pickez des commits main déjà fusionnés sur la branche de version uniquement pour corriger un bloqueur de version confirmé : une voie requise échouant de manière déterministe sur le candidat gelé, ou un défaut d'octets de mise à jour/installation/publication. Nommez chaque cherry-pick dans l'enregistrement de transfert. Non autorisé : rétroportages opportunistes, annulations de fonctionnalités, ou une nouvelle base prise pour "récupérer" une correction qui se cherry-picke proprement avec une petite résolution de conflit.

Les améliorations de processus de version effectuées pendant une version atterrissent sur les deux branches. Les modifications de workflow, de script de version, de test de version, de RELEASING.md, et de compétence de version fusionnent d'abord sur main, puis sont cherry-pickées (-x) sur release/YYYY.M.PATCH pour le prochain candidat ou correctif. Une réparation de qualification nécessaire pour cette version doit atterrir avant de geler un nouveau C/Q ; ne jamais échanger silencieusement le harnais pour un candidat déjà qualifié. Là où l'infrastructure CI seulement main est manquante sur la branche, conservez la forme d'expression de la branche et portez uniquement la logique. Le code produit sur la branche de version reste bloquant uniquement selon la règle ci-dessus.

Une version n'est pas terminée tant que tout ce qui a été ouvert pour elle est encore ouvert. Avant le rapport final, listez chaque PR créée pendant la version (gh pr list --author @me --state open plus toute PR liée à la session) et faites atterrir ou fermez explicitement chacune avec une raison ; confirmez que sa correction est sur main et, lorsqu'il s'agit d'outillage de version, sur la branche de version. Supprimez également les arbres de travail temporaires de la version, les branches de coupe locales abandonnées, et les arbres de travail scripts/pr obsolètes.

Les versions publiées et les tags finaux sont immuables. Réutilisez les artefacts source exacts réussis ; ne reconstruisez pas ou ne republiez pas comme une nouvelle tentative implicite. La version active est la file d'attente de travail : pas de correctifs opportunistes de déplacement de main ou de rétroportages. Classez les échecs, réparez leur propriétaire, réessayez la surface affectée, puis réévaluez au lieu de répéter la version complète.

Les preuves de publication requises et les approbations d'environnement imposées restent requises. Un frère réussi ne peut pas remplacer une preuve requise manquante. npm + ClawHub est le chemin prioritaire. La publication native macOS, Windows, Linux et Android s'exécute en parallèle et ne bloque jamais la finalisation npm/ClawHub, la publication GitHub Release ou la clôture principale. Les échecs CI de Node Windows sélectionné, de passerelle Linux/Windows/macOS et d'application native bloquent la validation de version. Les éditeurs de plateforme conservent leurs propres contrats d'artefact et de mise à jour ; signalez avec précision les plateformes en attente et les lacunes de preuve.