| 📦 Turbo Go 3d7798b k33g 13h ago | 1 | # Comment faire une release |
| 2 | |
| 3 | Ce guide montre comment publier une version pour que l'éditeur annonce correctement la sienne. Il suppose que vous pouvez pousser sur le dépôt. |
| 4 | |
| 5 | ## Vérifier ce que vous vous apprêtez à publier |
| 6 | |
| 7 | ```sh |
| 8 | make version |
| 9 | ``` |
| 10 | |
| 11 | ``` |
| 12 | v0.1.0-14-g88a4c38 (88a4c38) |
| 13 | ``` |
| 14 | |
| 15 | Quatorze commits après `v0.1.0`. Un `-dirty` à la fin signifie que vous avez des modifications non validées — validez-les ou mettez-les de côté d'abord, sinon la release portera ce suffixe pour toujours. |
| 16 | |
| 17 | ## Poser le tag |
| 18 | |
| 19 | ```sh |
| 20 | git tag -a v0.2.0 -m "v0.2.0" |
| 21 | git push origin v0.2.0 |
| 22 | ``` |
| 23 | |
| 24 | Le tag est l'origine du numéro : il doit exister avant de construire quoi que ce soit destiné à être distribué. Annoté (`-a`) plutôt que léger, parce que `git describe` préfère les tags annotés. |
| 25 | |
| 26 | ## Construire le binaire de release |
| 27 | |
| 28 | ```sh |
| 29 | make build |
| 30 | ./bin/turbo-go -version |
| 31 | ``` |
| 32 | |
| 33 | ``` |
| 34 | Turbo Go 0.2.0 (88a4c38, built 2026-08-31T18:04:05Z) |
| 35 | ``` |
| 36 | |
| 37 | Pas de suffixe `-14-g…` : vous êtes exactement sur le tag. C'est ce qui vous dit que le tag a bien été pris. |
| 38 | |
| 39 | ## Vérifier la boîte About |
| 40 | |
| 41 | Lancez l'éditeur et faites `Alt-H`, puis `A`. |
| 42 | |
| 43 | ``` |
| 44 | Turbo Go 0.2.0 |
| 45 | |
| 46 | A Turbo C-style editor for Go, |
| 47 | written in Go. |
| 48 | |
| 49 | Commit: 88a4c38 |
| 50 | Built: 2026-08-31 18:04 UTC |
| 51 | Theme: Turbo Classic |
| 52 | ``` |
| 53 | |
| 54 | ## Ou utiliser les scripts et laisser le workflow publier |
| 55 | |
| 56 | C'est ainsi qu'une release est réellement faite. Mettez la version et sa description d'une ligne dans `release.env` — il est ignoré par git, donc la CI ne le voit jamais : |
| 57 | |
| 58 | ```sh |
| 59 | TAG="v1.0.0" |
| 60 | ABOUT="Turbo Go" |
| 61 | ``` |
| 62 | |
| 63 | Puis lancez un seul script : |
| 64 | |
| 65 | ```sh |
| 66 | ./01-release.tag.sh |
| 67 | ``` |
| 68 | |
| 69 | Il lance `make check`, refuse un tag déjà pris en local ou sur `origin`, refuse un `go.mod` portant une directive `replace`, valide ce qui reste à valider, pousse la branche, et seulement ensuite pose le tag et le pousse. Cet ordre compte : un tag poussé avant la branche pointe sur un commit que le distant n'a jamais vu, et un tag créé avant un push refusé reste là pour que quelqu'un le trouve. |
| 70 | |
| 71 | C'est la dernière chose que vous lancez à la main. Le push du tag déclenche `.github/workflows/release.yml` ; suivez-le dans l'onglet Actions du dépôt. Il lance la suite de tests, compile les binaires avec `./02-build-releases.sh` — le même script que vous pouvez lancer sur votre machine — et crée la page de release avec : le message du tag, la ligne `go install`, les liens vers la documentation **à ce tag**, un binaire par plateforme, le `SHA256SUMS` et le README qui décrit les téléchargements. |
| 72 | |
| 73 | Le job publie avec son propre `GITHUB_TOKEN`, la seule authentification que l'API de release de Rickub accepte — un jeton personnel est refusé. Il n'y a rien à configurer et aucun secret à garder, ce qui explique la disparition des anciens `02-release.publish.sh` et `04-release.upload-binaries.sh`. |
| 74 | |
| 75 | `02-build-releases.sh` compile chaque plateforme et **estampille `TAG` lui-même**, en surchargeant la version du Makefile : `make ldflags VERSION=v1.0.0`. La release *est* `v1.0.0`, donc c'est ce que disent ses binaires — quoi qu'aurait répondu `git describe`, et que le tag existe déjà ou non. Il lance ensuite le binaire préparé pour cette machine et vérifie qu'il annonce bien la version : c'est la seule preuve que ce qui est distribué la porte. |
| 76 | |
| 77 | Vous pouvez voir ce que le workflow publiera sans rien publier, ou construire les binaires à la main : |
| 78 | |
| 79 | ```sh |
| 80 | ./02-build-releases.sh v1.0.0 # écrit release/v1.0.0/, ne pousse rien |
| 81 | ``` |
| 82 | |
| 83 | Sans argument il lit `TAG` dans `release.env` ; le workflow n'a pas de `release.env`, il passe donc le tag qui l'a déclenché. |
| 84 | |
| 85 | La suite de tests comprend des tests qui exécutent `01-release.tag.sh` contre un clone jetable. Ils se sautent eux-mêmes quand `TURBO_GO_RELEASING` est défini, ce que le script exporte avant d'appeler `make check` — retirer cette ligne fait récurser une release jusqu'à épuisement. Le workflow pose la même variable pour sa propre étape `go test`. |
| 86 | |
| 87 | ## Variantes |
| 88 | |
| 89 | - **Vous installez au lieu de distribuer un binaire.** `make install` et `scripts/install.sh` estampillent de la même façon, donc un éditeur installé nomme le commit dont il vient. Il n'y a rien de plus à faire. |
| 90 | - **Quelqu'un installe avec `go install`.** `go install rickub.com/turbo-editors/turbo-go@v0.2.0` annonce `0.2.0` d'après la version du module, sans commit ni date de build. C'est le propre enregistrement de l'outil Go ; rien à estampiller. |
| 91 | - **Vous avez tagué le mauvais commit.** Si le tag n'a pas été poussé, supprimez-le (`git tag -d v1.0.0`), taguez le bon, et reconstruisez. Une fois sur `origin`, ne le déplacez pas : le proxy de modules a mis en cache `go install …@v1.0.0` et la page de release porte déjà des binaires avec ce numéro — c'est pour cela que `01-release.tag.sh` refuse un tag qui existe. Incrémentez `TAG` et refaites une release. |
| 92 | - **About affiche `devel`.** Le binaire a été construit par un `go build .` nu plutôt que par `make`. Il n'a rien d'anormal ; simplement aucun tag ne lui a été estampillé, parce que le système de build de Go ne lit pas les tags git. Utilisez `make build`. |
| 93 | - **About affiche `unknown`.** Rien n'a nommé le build — un `go run .`, ou une construction depuis un dossier sans historique git. Utilisez `make build` depuis le dépôt cloné. |
| 94 | - **Vous n'avez pas git du tout**, ayant téléchargé une archive des sources. `make build` fonctionne quand même et le binaire annonce `unknown`. Passez la version vous-même si vous en avez besoin : |
| 95 | ```sh |
| 96 | go build -ldflags "-X 'rickub.com/turbo-editors/turbo-core/version.stamp=v0.2.0'" -o bin/turbo-go . |
| 97 | ``` |
| 98 | |
| 99 | ## Voir aussi |
| 100 | |
| 101 | - Toutes les sources du numéro, et ce qu'annonce chaque build : [Le numéro de version](../reference/versioning.md) |
| 102 | - Pourquoi il n'y a pas de constante de version dans les sources : [Décisions de conception](../explanation/design-decisions.md#la-version-est-une-propriété-du-build-pas-des-sources) |
| 103 | - Installer dans votre PATH : [Comment installer et construire Turbo Go](install.md) |