Processus de publication

Cette page décrit, à un niveau pratique, le processus normal de publication de Mindwtr. Elle est destinée aux mainteneurs travaillant depuis le dépôt.

Fichiers sources

L'automatisation des publications et les métadonnées de version sont principalement regroupées dans :

scripts/bump-version.sh
scripts/update-versions.js
docs/release-notes/
docs/release-notes/google-play/
metadata/
metadata/metadata.json
apps/desktop/src-tauri/linux/Mindwtr.metainfo.xml
https://github.com/dongdongbh/mindwtr-web/tree/main/docs pour les modifications de la documentation publique
wiki/ est retiré — il contient uniquement une page d'accueil renvoyant vers le site de documentation ; n'y ajoutez jamais de pages de contenu
.github/workflows/
.github/workflows/release-rc.yml pour l'automatisation des versions candidates

Cycle RC pour les publications bimensuelles

Utilisez un cycle de versions candidates pour les publications mineures bimensuelles habituelles. Il ne s'agit pas d'un programme bêta général. Une RC est le build destiné à devenir stable, sauf si les testeurs découvrent un problème bloquant.

Utilisez les noms de préversion SemVer :

première version candidate : v1.1.0-rc.1
correction ultérieure d'un problème bloquant : v1.1.0-rc.2
version stable finale : v1.1.0

Ne remplacez pas les artefacts d'une RC qui a atteint les testeurs. Corrigez ce cas avec le numéro de RC suivant. Si une exécution échoue avant que GitHub ne publie la préversion, annulez-la, corrigez main, supprimez et recréez la même étiquette RC sur le commit corrigé, puis renvoyez l'étiquette.

Exécutez ./scripts/bump-version.sh vX.Y.Z-rc.N pour une RC. Le script conserve les fichiers de version des applications et paquets sur la version stable de base (X.Y.Z), tout en écrivant la version RC complète dans apps/mobile/release-version.json pour les builds FOSS sans variable d'environnement. Le flux de travail RC vérifie les deux valeurs avant le démarrage des builds des plateformes.

Quand utiliser le cycle RC

Utilisez le cycle RC complet pour :

les publications mineures bimensuelles planifiées
les publications comportant des modifications multiplateformes
les publications qui touchent à la synchronisation, au stockage, à la capture, à l'empaquetage, aux droits, aux métadonnées du programme de mise à jour ou aux métadonnées des boutiques
les publications dans lesquelles plusieurs artefacts de distribution ont changé

Le mainteneur peut ignorer le cycle RC pour les publications correctives triviales, telles qu'une correction ciblée d'une ligne, une correction de documentation uniquement ou une mise à jour de métadonnées uniquement qui n'affecte pas le comportement de l'application installée. Cette omission doit être explicitement indiquée dans les notes de version ou la liste de contrôle de publication.

Matrice des canaux RC

Publiez les builds RC uniquement sur les canaux capables d'accueillir des testeurs sans engendrer une lourde charge de maintenance.

Plateforme	Canal RC	Comportement stable
Tous les téléchargements directs	Préversion GitHub	La version GitHub finale devient la source de téléchargement stable.
iOS	TestFlight	L'App Store reste le canal stable.
Apple Watch	Archive iOS avec Watch dans TestFlight	Les versions stables soumettent la même archive iOS avec Watch à la vérification de l’App Store et la distribuent via TestFlight.
Build macOS App Store	TestFlight	Le Mac App Store reste le canal stable.
Build Android Play	Tests internes Google Play et tests ouverts (`beta`) par défaut ; pistes fermées/personnalisées lorsqu'elles sont configurées	La production reçoit ultérieurement un téléversement stable, et la piste de tests internes est actualisée par le flux de travail stable.
Linux Flatpak	Branche bêta Flathub	Les versions stables sont publiées dans les branches stable et bêta afin que les utilisateurs bêta ne soient pas abandonnés.
Arch Linux	AUR `mindwtr-beta-bin`	La version stable actualise le paquet bêta persistant.
Linux Debian/Fedora	Dépôts APT/RPM bêta	Les paquets stables restent dans des répertoires de dépôt stable distincts.
Téléchargement direct Windows	Programme d'installation/version portable en préversion GitHub	La version GitHub finale fournit les téléchargements stables.
Windows Microsoft Store	Package flight Mindwtr Beta	Les versions stables actualisent le flight configuré et la soumission publique du Store.

Conservez les canaux suivants en version stable uniquement, sauf besoin manifeste et si l'automatisation est déjà en place :

F-Droid
IzzyOnDroid
winget
cask Homebrew stable
Chocolatey
bucket Scoop stable
dépôts APT/RPM stables

Les flights Microsoft Store utilisent la variable du dépôt MSSTORE_FLIGHT_ID et les secrets existants MS_TENANT_ID, MS_CLIENT_ID, MS_CLIENT_SECRET et, facultativement, MS_STORE_APP_ID. L’ID d’application par défaut est 9N0V5B0B6FRX. Exécutez .github/workflows/msstore-flight-id.yml pour obtenir l’ID du flight. Les testeurs inscrits reçoivent les mises à jour depuis la fiche habituelle du Store.

L’entrée RC run_msstore_flight est activée par défaut. Pour les RC, le flux Windows conserve run_msstore=false et utilise uniquement l’API des soumissions de flight. Il refuse les brouillons en attente qui ne lui appartiennent pas, y compris un premier brouillon créé dans Partner Center ; examinez-le et publiez-le ou abandonnez-le avant de réessayer. Ne modifiez pas dans Partner Center les soumissions créées par l’API. Le résumé du flux indique l’ID de soumission et l’état du traitement ; la certification et l’installation par les testeurs sont vérifiées séparément.

Pour reprendre un flight Store après la publication d’une version, .github/workflows/release-msstore-flight.yml accepte une étiquette stable ou RC déjà publiée. Le workflow vérifie l’archive Windows portable existante avec l’empreinte SHA256 de GitHub et empaquette l’exécutable inchangé. La soumission au flight exige que l’état de préversion corresponde à l’étiquette ; elle ne remplace pas les ressources publiques et ne reconstruit pas l’application.

Les versions des paquets utilisent X.Y.(Z*100+N).0 pour X.Y.Z-rc.N, avec des numéros RC de 1–98, et X.Y.(Z*100+99).0 pour la version stable X.Y.Z. Chaque composant doit être compris entre 0–65535 et le premier doit être positif. Par exemple, 1.3.0-rc.2 devient 1.3.2.0 et la version stable 1.3.0 devient 1.3.99.0. Le quatrième composant reste à zéro pour le Store. Les versions stables actualisent aussi le flight configuré, car les comptes inscrits lui restent affectés. Vérifiez qu’une mise à jour reçue du Store conserve les tâches et les pièces jointes.

Pour produire des installateurs Windows et des versions portables indépendantes, lancez manuellement Release Windows avec run_msstore et run_msstore_flight désactivés. La sélection d’une étiquette existante n’active pas la publication sur le Store, et ces builds acceptent des suffixes personnalisés comme 1.3.0-rc.2a sans appliquer les règles des versions de paquets du Store. La publication sur le Store public est activée par l’envoi d’une étiquette stable ou une demande explicite run_msstore ; les flights bêta utilisent run_msstore_flight.

Lancez le workflow depuis main pour utiliser ses dernières corrections. Le champ de l’étiquette de version sélectionne le code source d’une étiquette qui existe déjà dans le même dépôt ; il ne crée ni n’envoie d’étiquette. Créez et envoyez d’abord l’étiquette (dans votre fork si vous compilez depuis un fork), puis saisissez son nom exact, y compris le préfixe v éventuel.

Automatisation RC actuelle

Le flux de travail RC est .github/workflows/release-rc.yml.

L'envoi d'une nouvelle étiquette vX.Y.Z-rc.N démarre le flux de travail et vérifie l'étiquette, les versions stables de base, la version de publication FOSS validée et le commit de l'étiquette avant le démarrage des builds des plateformes. Une exécution qui a échoué sans qu'une préversion GitHub ait été publiée est récupérée en supprimant puis en recréant la même étiquette sur le commit corrigé. Si une version GitHub existe déjà pour l'étiquette, le flux de travail effectue uniquement la validation ; publiez les modifications sous le numéro de RC suivant. Utilisez workflow_dispatch uniquement pour des tentatives contrôlées sur certains canaux ou pour sélectionner des canaux différents de ceux par défaut.

Le flux de travail réutilise, dans la mesure du possible, les mêmes tâches de construction par canal que la version stable, puis crée une préversion GitHub à partir des artefacts Linux, macOS, Windows, Android et Android FOSS exacts.

Il publie également les builds destinés aux testeurs sur les canaux adossés aux boutiques qui sont déjà raccordés :

AAB Android vers Google Play internal et les tests ouverts (beta) par défaut. Pour les RC manuelles, play_track sélectionne des pistes de test supplémentaires séparées par des virgules ; none signifie tests internes uniquement. Utilisez run_play_testing=false pour désactiver tout téléversement vers Play.
Archive iOS avec Watch vers TestFlight avec la soumission à la vérification de l'App Store désactivée. La tâche iOS de la RC sélectionne cette variante, attend son traitement et distribue ce build précis au groupe de test externe configuré.
Build macOS App Store vers TestFlight avec la soumission à la vérification de l'App Store désactivée.
MSIX Windows vers le flight Microsoft Store Mindwtr Beta ; les exécutions manuelles peuvent désactiver ce canal.
Pull requests de mise à jour de la branche bêta Flathub par l'intermédiaire du flux de travail Flathub partagé ; les exécutions manuelles peuvent les désactiver lorsque la configuration du canal n'est pas prête.
Lorsque les ressources de la préversion GitHub sont disponibles, le flux compile et valide AUR mindwtr-beta-bin, publie les fichiers exacts PKGBUILD et .SRCINFO dans AUR, puis vérifie le commit Git distant.
Mises à jour des dépôts APT/RPM bêta après la création de la préversion GitHub ; les exécutions manuelles peuvent les désactiver.

Le fichier stable release.yml reste le flux de travail de publication stable. Il est protégé de façon à ce que les étiquettes de préversion ne publient pas vers des canaux réservés aux versions stables, comme la production Google Play, le Microsoft Store, Snap stable, les dépôts Linux APT/RPM, Flathub stable, AUR stable, Scoop, winget, Homebrew ou Chocolatey.

Le flux de travail iOS réutilisable sépare l’inclusion de la Watch (include_watch) du routage réservé à TestFlight (testflight_only). Ces deux entrées valent false par défaut pour les appels ponctuels. Le flux RC active les deux et produit ainsi un build avec Watch réservé à TestFlight, sans modifier la version de production de l’App Store. Le flux stable active la Watch et désactive le routage réservé à TestFlight : une seule archive est soumise à la vérification de l’App Store et distribuée via TestFlight. Une récupération stable manuelle sélectionne run_ios_appstore ; il n’existe plus de tâche distincte pour téléverser la Watch.

La bêta Flathub nécessite la branche bêta et les autorisations dans flathub/tech.dongdongbh.mindwtr. Les versions stables publient le paquet AUR mindwtr-bin depuis release.yml après une validation dans un conteneur propre et un contrôle de propriété. Le paquet mindwtr compilé depuis les sources est maintenu par la communauté et ne fait pas partie du processus de publication. Les builds RC publient mindwtr-beta-bin par update-aur-beta.yml avec les mêmes contrôles de sécurité. Si l’AUR désactive les poussées pendant une maintenance, relancez ce canal lorsqu’elles reprennent.

Étant donné qu'un téléversement vers une piste de test Play consomme un versionCode Android, chaque RC téléversée vers Play nécessite un nouveau versionCode. Le flux de travail RC détermine ce code une seule fois avant le démarrage des builds Android ; le build Play et le build Android FOSS utilisent ensuite le même résultat de prévalidation et s'exécutent en parallèle. Le flux de travail téléverse un AAB et attribue le même versionCode à chaque piste de test configurée. Le processus stable final actuel doit lui aussi utiliser un nouveau téléversement en production avec un versionCode supérieur, ou un futur flux de travail de promotion stable doit promouvoir le build Play déjà testé. Ne créez pas d'étiquette de version stable finale avec un versionCode Android déjà téléversé sur Play, sauf si le flux de travail stable a été adapté pour promouvoir ce build existant.

Les tests internes utilisent le même AAB standard, sans profilage activé, et le même versionCode que les tests ouverts. Les RC affectent cet unique téléversement à internal et beta par défaut ; les versions stables affectent un unique téléversement à production, beta et internal. Il n’y a ni AAB interne distinct ni code de version interne supplémentaire. Conservez des builds APK et AAB standard séparés. Les anciens builds avec profilage déjà téléversés comptent toujours dans le code de version maximal actuel de Play.

Calendrier

Les canaux dont la vérification prend du temps doivent disposer d'une longueur d'avance. Utilisez ce calendrier par défaut :

Jour	Action
T-7 à T-5	Gel des fonctionnalités. Seuls les correctifs, les notes de version, les métadonnées et les problèmes bloquant la publication sont autorisés.
T-5	Créez la branche de publication, exécutez `./scripts/bump-version.sh vX.Y.Z-rc.1`, générez des notes de version propres à la RC, telles que `docs/release-notes/X.Y.Z-rc.1.md`, puis créez l'étiquette `vX.Y.Z-rc.1` afin que `release-rc.yml` téléverse les canaux de testeurs activés.
T-4	Exécutez des contrôles rapides sur les artefacts de chaque canal à mesure que les builds vérifiés deviennent disponibles. Ne corrigez que les problèmes bloquants.
T-3	Confirmez la préversion GitHub créée par `release-rc.yml`, vérifiez la pull request Flathub bêta et la mise à jour AUR de `mindwtr-beta-bin` lorsque ces entrées étaient activées, puis annoncez la RC aux testeurs.
T-2 à T-1	Triez les retours. Ne créez une `rc.2` que pour les problèmes bloquants. Les problèmes non bloquants sont reportés au cycle suivant.
Jour de publication	Créez l'étiquette `vX.Y.Z`, publiez la version stable partout et mettez également à jour tous les canaux de test persistants existants vers la version stable.
T+1 à T+2	Surveillez les plantages, les issues GitHub, Discord, les commentaires des boutiques et les rapports des paquets en aval. Appliquez si nécessaire un correctif avec l'étiquette corrective suivante, par exemple `v1.1.1` après `v1.1.0`.

Seuil de blocage pour rc.2

Ne créez une nouvelle RC que pour l'un des problèmes bloquants suivants :

plantage au lancement
perte ou corruption de données
corruption de la synchronisation ou échec reproductible de la synchronisation
échec de l'installation, de la mise à jour, de la signature, des droits ou de l'empaquetage
capture, création, modification ou achèvement des tâches défaillant
migration depuis la version stable précédente défaillante
régression grave propre à une plateforme sur un canal pris en charge

Tout le reste attend la prochaine publication planifiée ou une version corrective ultérieure. Cela empêche le cycle bimensuel de se transformer en boucle bêta sans fin.

Contrôles rapides RC obligatoires

Chaque canal de distribution constitue un environnement d'exécution différent. La RC n'est pas prête tant que l'artefact de chaque canal RC n'a pas été lancé dans un environnement fidèle au canal, dans la mesure permise par la CI ou les tests locaux.

Contrôles rapides minimums :

lancer l'artefact exact que les utilisateurs reçoivent
créer, modifier, terminer et supprimer une tâche
vérifier que la capture ou l'ajout rapide s'ouvre et s'enregistre
vérifier que l'application peut lire les données existantes de la version stable précédente
vérifier que les paramètres de synchronisation s'ouvrent sans plantage
vérifier le comportement au démarrage propre au programme de mise à jour, à la boutique ou au bac à sable, le cas échéant
vérifier que les journaux ne présentent pas d'erreurs fatales au démarrage

Pour les canaux ayant déjà connu des défaillances, conservez des contrôles propres à chaque canal :

l'APK FOSS et l'APK/AAB Play constituent des ensembles de dépendances distincts
Flatpak doit être lancé dans l'environnement d'exécution Flatpak
les paquets AUR doivent être construits dans un conteneur Arch propre avant leur publication
les paquets MSIX/Microsoft Store ne doivent pas échouer de façon irrécupérable à cause de la barre d'état système, des raccourcis ou des capacités limitées par le bac à sable
les builds App Store et TestFlight doivent conserver les droits requis

Annonce aux testeurs

L'annonce de la RC doit être courte et exploitable :

version et liens vers les canaux
principales modifications visibles par les utilisateurs
risques connus ou aspects à tester
voie précise pour les retours : issue GitHub, canal Discord ou e-mail
rappel qu'il s'agit d'une version candidate, pas d'un aperçu de fonctionnalité

Processus de publication stable

Assurez-vous que main se trouve dans l'état prévu pour la publication et validez d'abord tout travail préparatoire à la publication.
- Si la version précédente est déjà publiée, placez les correctifs ultérieurs dans docs/release-notes/unreleased.md et ajoutez un lien depuis CHANGELOG.md jusqu'à ce que la prochaine version corrective soit préparée, par exemple v0.9.1 après v0.9.0.
Incrémentez la version avec :

bash

./scripts/bump-version.sh 0.x.y

Cette commande met à jour les versions des paquets de l'espace de travail et incrémente le versionCode Android.

Si Google Play possède déjà un versionCode supérieur provenant de téléversements RC ou destinés aux testeurs, transmettez cette valeur maximale au script d'incrémentation avant de créer l'étiquette :

bash

ANDROID_REMOTE_MAX_VERSION_CODE=85 ./scripts/bump-version.sh 0.x.y

Le script écrit dans apps/mobile/app.json suivi par Git une valeur supérieure au maximum de Play ; l'étiquette de publication, l'APK GitHub et les recettes de build reproductible en aval utilisent ainsi les mêmes métadonnées Android. La CI de publication stable rejette toujours les remplacements de versionCode appliqués uniquement dans la CI ; corrigez les métadonnées sources avant de créer l'étiquette au lieu de vous appuyer sur une mutation non suivie dans le flux de travail.

Exécutez les contrôles stricts de publication avant de créer l'étiquette :
- Contrôle des types/tests :
  - bun run test
  - bun run typecheck
  - bun run native:test
- Contrôle FOSS/statique :
  - inspectez git diff vPREV..HEAD -- apps/mobile/package.json
  - inspectez les fichiers de configuration F-Droid/FOSS (apps/mobile/plugins/android-manifest-fixes.js, apps/mobile/scripts/, .github/workflows/release-android-foss.yml, config/izzyonandroid.yml)
  - exécutez python3 scripts/ci/repair-package-lock.py --check apps/desktop/package-lock.json
- Contrôle du schéma CloudKit :
  - comparez les fichiers de schéma synchronisés à l'étiquette précédente
  - si un nouveau champ ou type d'enregistrement adossé à CloudKit a été ajouté, mettez à jour/déployez le schéma de production avant la publication
Préparez ou mettez à jour les notes de version et les métadonnées :
- docs/release-notes/<version>.md
- docs/release-notes/google-play/<version>.txt
- metadata/*/release_notes.txt
- metadata/*/changelogs/<androidVersionCode>.txt
- metadata/metadata.json
- apps/desktop/src-tauri/linux/Mindwtr.metainfo.xml
Mettez à jour la documentation publique dans les sources de la documentation web de Mindwtr lorsque les détails du processus de publication/documentation changent. Le wiki GitHub est retiré ; n'ajoutez ni ne mettez à jour de pages de contenu dans wiki/ et n'exécutez pas Git dans un checkout .wiki distinct.
Examinez attentivement les modifications de version et de métadonnées obtenues.
Validez la préparation de la publication :

bash

git add -A
git commit -m "chore(release): v0.x.y"

Créez l'étiquette de publication :

bash

git tag v0.x.y

Envoyez main et l'étiquette :

bash

git push origin main --tags

Laissez GitHub Actions publier les artefacts des plateformes et toutes les tâches d'empaquetage en aval.

Déploiements progressifs sur les boutiques

Les publications stables arrivent sur Google Play et le Microsoft Store sous forme de déploiements progressifs : 5 %, puis 20 %, 50 % et 100 %. Le workflow Manage Store Rollout (rollout.yml) avance d'une étape au maximum par exécution quotidienne ; un déploiement reste donc ouvert plusieurs jours. Chaque boutique n'accepte qu'un seul déploiement de production ouvert : le précédent doit être finalisé ou arrêté avant de pousser l'étiquette stable suivante, sinon les tâches de publication Play et Microsoft Store échouent et aucune version GitHub n'est créée. Voir Déploiements sur les boutiques pour le calendrier, les actions manuelles et la procédure d'arrêt.

Signature de code Windows

Le workflow de publication est prêt à signer les versions Windows avec Authenticode via SignPath Foundation, mais aucun téléchargement publié n'est actuellement confirmé comme signé. Lorsque le certificat de publication et la configuration des artefacts SignPath seront prêts, le bloc de signature de .github/workflows/release-windows.yml exécutera deux tours de signature par publication, et l'ordre compte :

tauri build --no-bundle s'arrête au mindwtr.exe isolé, qui est signé en premier. L'installateur NSIS intègre sa propre copie de ce binaire : un installateur empaqueté avant la signature déposerait donc un exe non signé sur chaque machine. L'exe signé alimente aussi le ZIP portable et la disposition MSIX.
tauri bundle construit ensuite l'installateur autour de l'exe signé, et mindwtr-setup.exe est signé lors d'un second tour.

Chaque tour est une soumission SignPath distincte, sous forme d'un zip contenant exactement un fichier ; la politique release-signing demande donc deux approbations manuelles par publication, chacune avec un délai de 30 minutes avant l'échec de la compilation. Les tours ne peuvent pas être fusionnés : l'installateur n'existe pas tant que l'exe n'est pas signé. Le processus stable comme celui des RC appellent ce travail, une étiquette RC coûte donc les deux mêmes approbations.

L'ensemble du bloc dépend du dépôt dongdongbh/Mindwtr, de la variable de dépôt SIGNPATH_SIGNING_ENABLED définie à true, de la présence des deux secrets SignPath et d'une étiquette. Les forks, les demandes de tirage et les exécutions manuelles sans étiquette produisent volontairement des versions non signées. La variable est l'interrupteur principal : si elle n'est pas définie, les étapes de signature sont ignorées en silence et la version est publiée non signée, sans aucune vérification en échec pour le signaler.

Avant la prochaine publication signée, la configuration des artefacts dans l'interface SignPath doit être mise à jour pour correspondre aux deux soumissions à fichier unique. C'est une action de mainteneur en dehors de ce dépôt — la modification du workflow ne suffit pas — et elle invalide la validation précédente en signature de test, qui reposait sur l'ancienne soumission unique contenant les deux fichiers.

Avant de créer l'étiquette

Vérifiez au minimum que :

les notes de version existent et correspondent aux modifications réelles
les versions des paquets sont alignées dans tout le monorepo
apps/mobile/release-version.json contient la version RC complète pour une étiquette RC
le versionCode Android a été incrémenté
le verrou de paquet de bureau réussit repair-package-lock.py --check
la configuration FOSS supprime toujours les autorisations bloquées et ne conserve que celles qui sont voulues
le schéma adossé à CloudKit n'a pas changé, ou le schéma de production a été mis à jour au préalable
les modifications des métadonnées des boutiques/publications sont intentionnelles et limitées à chaque plateforme
les catégories des boutiques mobiles dans les consoles sont toujours correctes : Google Play Productivity > Task Management et catégorie principale de l'App Store Productivity
les textes des paramètres régionaux de Google Play respectent la limite de 500 caractères de l'API
la configuration des artefacts SignPath correspond au processus de signature Windows actuel à deux soumissions
aucun déploiement de production de la publication stable précédente n'est encore ouvert sur Google Play ou le Microsoft Store ; finalisez-le ou arrêtez-le d'abord

Pour les publications plus importantes, vérifiez également :

les métadonnées du programme de mise à jour de bureau
les métadonnées des boutiques mobiles / entrées Fastlane
les modifications du site de documentation relatives aux fonctionnalités visibles par les utilisateurs dans les sources de la documentation web de Mindwtr
la synchronisation entre moteurs avec un petit jeu de données initial : les ajouts, mises à jour, suppressions et transferts de pièces jointes doivent converger entre Cloud, la synchronisation WebDAV/par fichier et tout moteur natif de plateforme disponible pour le testeur de la publication ; une deuxième synchronisation ne doit signaler aucun nouveau conflit

Notes de version

Les notes de version numérotées se trouvent dans docs/release-notes/.

Directives :

gardez le résumé initial centré sur l'utilisateur
présentez d'abord les correctifs/fonctionnalités importants
répertoriez les commits notables lorsque cela est utile
pour les RC, utilisez docs/release-notes/X.Y.Z-rc.N.md ou docs/release-notes/vX.Y.Z-rc.N.md et indiquez la version RC complète dans le premier titre ; réservez docs/release-notes/X.Y.Z.md à la version stable finale
pour les versions stables, la première ligne doit être exactement # Mindwtr X.Y.Z ou # Mindwtr vX.Y.Z ; release.yml rejette les autres titres
maintenez les extraits Google Play dans docs/release-notes/google-play/ alignés si nécessaire
mettez à jour metadata/*/release_notes.txt pour les notes de version de l'App Store
ajoutez le nouveau fichier de journal des modifications Android sous metadata/*/changelogs/<versionCode>.txt
maintenez les notes de version du Microsoft Store dans metadata/metadata.json alignées sur la même version
ajoutez ou actualisez l'entrée AppStream en tête de apps/desktop/src-tauri/linux/Mindwtr.metainfo.xml

Contrôles après publication

Après l'envoi de l'étiquette :

vérifiez la création de la version GitHub
vérifiez que les artefacts de bureau/mobiles attendus sont joints
vérifiez que les flux de travail propres aux boutiques ont réussi, le cas échéant
contrôlez ponctuellement les surfaces de mise à jour/téléchargement par rapport à la nouvelle version
vérifiez que la version stable a également été publiée sur les canaux de test persistants existants, afin que les testeurs restent sur le build le plus récent

Approche de la restauration

Si une mauvaise version est détectée :

interrompez toute nouvelle création d'étiquette jusqu'à ce que le mode de défaillance soit compris
privilégiez une version corrective rapide qui avance plutôt que de réécrire l'historique publié
indiquez explicitement le correctif dans les notes de version

Processus de publication ​

Fichiers sources ​

Cycle RC pour les publications bimensuelles ​

Quand utiliser le cycle RC ​

Matrice des canaux RC ​

Automatisation RC actuelle ​

Calendrier ​

Seuil de blocage pour rc.2 ​

Contrôles rapides RC obligatoires ​

Annonce aux testeurs ​

Processus de publication stable ​

Déploiements progressifs sur les boutiques ​

Signature de code Windows ​

Avant de créer l'étiquette ​

Notes de version ​

Contrôles après publication ​

Approche de la restauration ​

Pages connexes ​

Processus de publication

Fichiers sources

Cycle RC pour les publications bimensuelles

Quand utiliser le cycle RC

Matrice des canaux RC

Automatisation RC actuelle

Calendrier

Seuil de blocage pour rc.2

Contrôles rapides RC obligatoires

Annonce aux testeurs

Processus de publication stable

Déploiements progressifs sur les boutiques

Signature de code Windows

Avant de créer l'étiquette

Notes de version

Contrôles après publication

Approche de la restauration

Pages connexes