annonce-de-version-openclaw

Annonce de version OpenClaw

À utiliser avec release-openclaw-maintainer après qu'une version soit en ligne. À utiliser avec $discord-user-post pour poster effectivement sur Discord en tant qu'utilisateur connecté.

D'abord les preuves

Avant de rédiger les axes de test, lisez les preuves réelles de la version :

1. Le corps de la version GitHub et le tag immuable ; pour extended-stable, confirmez également la portée limitée npm/conteneur et la classification non-Latest.
2. Le CHANGELOG/<version>.md de la version de base publiée et l'enregistrement des contributions, résolus avec node scripts/release-changelog.mjs read --version <version> [--ref <sha-or-tag>] (ajoutez --record pour la comptabilité). Le résolveur partagé lit les tags monolithiques historiques ; le CHANGELOG.md actuel est un index. Après la publication approuvée de la documentation, lisez le miroir complet de la documentation et l'enregistrement figé plutôt que de traiter le corps GitHub compact comme des notes complètes.
3. Les commits depuis la version précédemment livrée ou la base spécifiée par l'opérateur.
4. Les métadonnées du registre/package pour la version exacte et le dist-tag actuel.
5. L'état de validation pertinent pour la confiance des utilisateurs.

N'affirmez pas un audit complet du journal des modifications si vous ne l'avez pas fait. Si vous n'avez lu que les notes de version générées ou une section sélectionnée du journal, dites-le et soit auditez correctement, soit rédigez avec cette limitation.

Pour les axes de test bêta, priorisez les changements observables par l'utilisateur plutôt que les mécanismes de test internes ou CI :

• chemins d'installation/mise à jour
• comportement OS/plateforme spécifique
• démarrage/redémarrage de la passerelle, configuration et comportement à l'exécution
• routage fournisseur/modèle/runtime
• chargement de plugins et développement local de plugins
• canaux et chemins multimédia
• correctifs de sécurité/perte de données/impact utilisateur

Ne laissez pas les correctifs tardifs de branche de version dominer automatiquement l'annonce. Si la version inclut un delta important par rapport à la version précédemment livrée, classez les axes de test par le delta complet de la version et l'impact utilisateur attendu ; mentionnez les correctifs tardifs dans leur catégorie naturelle.

Texte obligatoire

Chaque annonce bêta doit rendre explicite le statut bêta et inclure :

• la version exacte, par ex. OpenClaw 2026.5.25-beta.1
• une phrase de cadrage du risque : bêta, utile pour les tests, pas une promotion stable
• des axes de test ciblés dérivés des preuves, pas de suppositions
• la commande de mise à jour mise en avant près du haut :

  openclaw update --channel beta --yes
  openclaw --version
  

• le chemin d'installation fraîche : Installer depuis https://openclaw.ai
• le lien vers la version GitHub
• une note de validation concise, sans faire de CI le titre

Ne suggérez pas de commandes d'installation npm dans les annonces bêta, sauf si l'opérateur demande explicitement un texte spécifique à npm ou un dépannage. Il est acceptable d'utiliser les métadonnées du registre comme preuve ; ne les transformez pas en instruction d'installation publique.

Pour les annonces stables, utilisez le libellé du canal stable :

openclaw update --channel stable --yes
openclaw --version

Les installations fraîches pointent toujours vers https://openclaw.ai.

Pour extended-stable, nommez la version exacte et le mois de fin. Mentionnez uniquement les rétroportages observables, et utilisez :

openclaw update --channel extended-stable
openclaw --version

N'ajoutez pas --yes : les utilisateurs venant d'une stable régulière plus récente doivent voir l'avertissement de rétrogradation car les versions plus anciennes peuvent ne pas comprendre la configuration plus récente. Liez la version GitHub, mais n'héritez pas des affirmations macOS, Windows, ClawHub, latest ou du site web de la stable régulière.

Style

• Markdown Discord, pas de tableaux.
• Gardez-le parcourable : courte intro, puces, commandes, liens.
• Commencez par ce que les utilisateurs peuvent ressentir ou tester, pas par la plomberie de preuve.
• Ne mentionnez la validation qu'après les instructions d'installation/mise à jour.
• Soyez précis sur l'endroit où les retours sont utiles.
• Ne mentionnez pas les chemins de preuve locale privée dans les annonces publiques.
• Ne surestimez pas les plateformes, canaux ou comportements de fournisseur non vérifiés.

Publication

Lorsqu'on vous demande de poster, utilisez $discord-user-post pour manipuler l'application de bureau Discord connectée en tant qu'utilisateur. Résolvez et vérifiez visiblement le serveur/canal exact, inspectez le corps final, et demandez une confirmation au moment de l'action avant de le saisir ou de l'envoyer. N'utilisez jamais d'envois de canal OpenClaw, de bots, de webhooks, de relais ou de jetons.