Releases de bureau BaoCut
Ceci est l'application Electron v3 (com.baocut.app). L'ancienne compétence baocut-app est une référence, pas le workflow exécutable de ce checkout. Gardez cette compétence de développement en dehors du dossier skills/ de l'application ; n'invoquez pas les anciennes releases GPUI/npm/Homebrew.
Sélectionner le workflow
| Intention de l'utilisateur | Lire et suivre |
|---|---|
| Demande de release/publication ordinaire ; aucune méthode spécifiée | Release par tag — par défaut. Pushez le tag source gelé ; publiez d'abord le Mac arm64 vérifié, puis ajoutez Windows CPU/CUDA/Vulkan à la même Release. |
| Package/candidat local explicite, release traditionnelle ou manuelle, récupération/continuation sur une seule plateforme | Release traditionnelle. Respectez les plateformes demandées et la portée locale/uniquement publique. |
| Identité de signature, sauvegardes portables ou informations d'identification GitHub uniquement | Signature/sauvegardes. Ne créez pas de tag et ne publiez pas. |
Chargez uniquement la référence nécessaire pour l'intention sélectionnée. Ne demandez pas aux utilisateurs de choisir entre les deux méthodes de release lorsqu'ils n'en ont pas spécifié une : utilisez la release par tag. Ne retombez pas silencieusement sur l'empaquetage traditionnel après un échec d'Actions. Une instruction spécifique locale ou propre à une plateforme outrepasse la portée toutes plateformes par défaut ; suivez la méthode et les limites explicites de l'utilisateur.
Contraintes partagées de release
- Inspectez l'état git avant les modifications ; préservez le travail non lié ou simultané. Validez les modifications source appartenant à la tâche avant de geler une release. Suivez les règles de validation du dépôt, d'autorisation de push de la tâche en cours et de nettoyage de l'arbre de travail ; ne réutilisez pas l'autorisation de push d'une autre tâche et ne la demandez pas à nouveau si elle a déjà été accordée ici.
apps/desktop/package.jsonpossède la version de l'application. Synchronisez la version racine et le lockfile via npm ; ne modifiez pas les versions Cargo ou de protocole pour une release de l'application.- Interrogez les releases/flux réels avant de choisir un build. Les builds augmentent strictement ; les tags/fichiers déjà publiés sont immuables.
- Liez le tag et tous les artefacts de plateforme à un seul SHA source complet. N'expédiez jamais de binaires avec sources sales, de matériel de signature privé ou de soumissions intermédiaires de notaire.
- Publiez la Release Mac, son journal des modifications consolidé et les liens de téléchargement vérifiés dès que le candidat Mac réussit ; les builds Windows/CUDA ne bloquent pas cette étape. Les mises à jour ultérieures de cette plateforme mettent à jour les actifs, les notes et les flux de cette Release, jamais le tag Git ni son SHA source. Signalez les plateformes en attente séparément ; avancez la version Latest à l'étape de finalisation ci-dessous.
- Pour chaque nouvelle version/build publiée, suivez les notes de release : inventoriez la gamme complète des commits/PR, résumez les grandes plages par lots, réconciliez la couverture et publiez le journal des modifications consolidé. Un candidat local conserve les mêmes notes localement ; la continuation de plateforme réutilise la gamme de la version existante.
- Après chaque release publique ou continuation de plateforme, vérifiez les liens de téléchargement à l'aide de liens de téléchargement. Les README et baocut.com pointent vers
baocut.com/download/<id>, qui suit lui-même les GitHub Releases. Ne modifiez pas les README et ne redéployez pas le site pour une release ; vérifiez que baocut.com sert le nouveau build. - Signalez les vérifications et les sauts réels. Un push de tag ou une vérification d'identifiants ne constitue pas une release terminée ; la publication nécessite des jobs réussis, une relecture publique, des flux, des notes de release vérifiées et une vérification de téléchargement baocut.com réussie.
Compléter la release publique
Une fois que toutes les plateformes sélectionnées ont été publiées, que les actifs et flux publics ont passé la relecture, et que les notes de release consolidées sont vérifiées, marquez la dernière release stable de bureau comme Latest dans l'onglet Releases de GitHub :
gh release edit "$release_tag" --repo "$release_repo" --latest
gh api "repos/$release_repo/releases/latest" --jq '.tag_name'
Utilisez le dépôt et le tag vérifiés pour cette tâche ; la relecture doit correspondre à ce tag. Les éditeurs de plateforme préservent la précédente version Latest pendant la validation et les téléchargements, donc cette étape finale est requise même lorsque Actions réussit. Les candidats locaux, brouillons et préversions n'avancent pas Latest. Lors de la poursuite d'une release plus ancienne, conservez une version/build de bureau publiée plus récente comme Latest. Incluez le tag Latest vérifié dans le rapport d'achèvement.
Le guide de bureau possède les mécanismes d'empaquetage ; les références spécifiques au mode expliquent quand le charger. Les demandes visant uniquement à modifier la configuration de release ne doivent pas créer de tag de release ni publier.