Publier une version de Sidekicks

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

# Publier une version de Sidekicks

[English](RELEASING.md)

Trois étapes, sur le Mac : tout construire, tagger, attacher les fichiers.

| Étape | Commande | Résultat |
| --- | --- | --- |
| 1. Construire | `make release-build` | `dist/` : les paquets macOS (Apple Silicon) et Windows (x86-64 et Arm), et `SHA256SUMS` |
| 2. Tagger | `make release-tag` | le tag `v<version>` est poussé ; le workflow **Release** crée la release sur Rickub, avec ses notes |
| 3. Attacher | à la main, sur la page de la release | tous les fichiers de `dist/` attachés à la release |

La version est `info.version` dans `build/config.yml` ; le tag est `v` + cette version.

## Avant : fixer la version

1. Dans `build/config.yml`, réglez `info.version` (par exemple `"0.2.0"`).
2. `wails3 task common:update:build-assets`, puis remettez `LSMinimumSystemVersion` à `13.0.0` dans `build/darwin/Info.plist` et `build/darwin/Info.dev.plist` (la commande le remet à `12.0.0`).
3. `make verify` ([vérifications avant de fusionner](docs/fr/how-to/verifier-avant-de-fusionner.md)), commitez, fusionnez dans `main`, puis `git checkout main && git pull`.

## 1. Construire

```bash
make release-build
```

Il construit, dans `dist/` :

| Fichiers | Comment |
| --- | --- |
| `Sidekicks-<v>-macos-arm64.dmg`, `.zip` | en natif, pour Apple Silicon seulement (outils en ligne de commande de Xcode) |
| `Sidekicks-<v>-windows-amd64-installer.exe`, `sidekicks_<v>_windows_amd64.zip` | compilés depuis le Mac (demande `brew install makensis`) |
| `Sidekicks-<v>-windows-arm64-installer.exe`, `sidekicks_<v>_windows_arm64.zip` | compilés depuis le Mac, pour Windows sur Arm |
| `SHA256SUMS` | sur tous les fichiers ci-dessus |

Pas de paquets Linux dans les releases pour le moment : `LINUX_ARCHES=amd64 make release-build` les construit aussi, dans Docker. `SKIP="windows"` (ou `macos`) laisse un système de côté ; `WINDOWS_ARCHES=amd64` ne construit qu'une architecture Windows. La liste des fichiers d'une release est `scripts/package.sh release-names`.

## 2. Tagger

```bash
make release-tag
```

Il refuse si la copie de travail a des modifications, si vous n'êtes pas sur `main`, si `main` diffère de `origin/main`, ou si le tag existe ; il avertit s'il manque un paquet dans `dist/`. Puis il crée le tag annoté `v<version>` et le pousse. Le push lance `.github/workflows/release.yml`, qui vérifie que le tag correspond à `build/config.yml` et crée la release avec des notes qui listent les fichiers attendus.

## 3. Attacher

Ouvrez la release sur Rickub (**Releases → v<version>**) et attachez tous les fichiers de `dist/`, `SHA256SUMS` compris.

## En cas de problème

| Symptôme | Que faire |
| --- | --- |
| `makensis is missing` | `brew install makensis` — ou `SKIP=windows`. |
| `the tag v… already exists` | Cette version a déjà été publiée : augmentez `info.version`. |
| Le workflow a échoué : « The tag is … but build/config.yml says … » | Supprimez le tag (`git push origin :refs/tags/v…` et `git tag -d v…`), corrigez `info.version`, recommencez. |
| Le workflow a tourné mais aucune release n'est apparue | Le journal du job dit pourquoi (un `403` veut dire que le jeton n'a pas pu écrire : `permissions: contents: write` doit rester dans `release.yml`). Créez la release à la main sur Rickub depuis le tag ; les notes sont dans le journal du job. |

Détails : [Publier une release](docs/fr/how-to/publier-une-release.md) · [référence des commandes](docs/fr/reference/commandes.md).