# Comment publier la bibliothèque

Ce guide montre comment publier une version de turbo-core dont les éditeurs peuvent dépendre. Il suppose un accès en écriture au dépôt.

turbo-core est un module Go sans binaire et sans artefact de publication : le publier, c'est le taguer. `01-release.tag.sh` fait tout.

## Étapes

### 1. Dire quelle version

Créez `release.env` — il est ignoré par git, car un jeton de publication a aussi sa place dans un fichier de ce genre :

```sh
TAG="v0.1.0"
ABOUT="La bibliothèque des éditeurs Turbo"
```

### 2. Lancer le script

```bash
./01-release.tag.sh
```

Il lance `make check`, refuse un tag déjà pris ici ou sur origin, refuse un `go.mod` portant une directive `replace`, valide ce qui traîne, pousse la branche, et seulement ensuite pose le tag et le pousse.

Cet ordre compte : un tag poussé avant la branche désigne un commit que le dépôt distant n'a jamais vu, et un tag créé avant un push refusé reste derrière, à la charge de qui le trouvera.

### 3. Créer la page de release

Le tag suffit pour `go get` ; ceci ajoute la page qu'une personne lit.

```bash
./02-release.publish.sh --dry-run    # montre la requête, n'envoie rien
./02-release.publish.sh              # la crée
```

Il lui faut `curl` et `jq`, `OWNER` et `REPO` dans `release.env`, et un jeton d'application Codeberg dans `turbo-core.token.env` — un fichier à part pour que `release.env` puisse être montré à quelqu'un sans fuite. Les deux sont couverts par `*.env` dans `.gitignore`.

Les notes qu'il écrit sont `ABOUT`, la ligne unique qui installe le module, et des liens vers la documentation **à ce tag** plutôt qu'à la branche.

Il n'y a ni `03` ni `04` ici. Ceux-là construisent et attachent des binaires dans les éditeurs ; une bibliothèque n'en a pas — son artefact est le tag.

### 4. Y brancher les éditeurs

Un éditeur à la fois, en lançant sa suite avant de passer au suivant :

```bash
go mod edit -require=codeberg.org/turbo-editors/turbo-core@v0.1.0
go mod edit -dropreplace=codeberg.org/turbo-editors/turbo-core
go mod tidy
make test
```

Tous les éditeurs dépendent de la même bibliothèque : un changement qui casse l'un casse en général les autres, et l'apprendre trois fois de suite coûte moins cher que l'apprendre dans une publication.

## Variantes

### Vous préférez le faire à la main

```bash
make check
git push origin main
git tag -a v0.1.0 -m "La bibliothèque des éditeurs Turbo"
git push origin v0.1.0
```

Poussez la branche **avant** le tag, pour la raison ci-dessus.

### Vous développez à travers les trois dépôts

Depuis la v0.1.0, les éditeurs dépendent du module publié et ne portent plus de `replace` : un changement de bibliothèque leur est donc invisible tant qu'il n'est pas publié. Ne publiez pas pour savoir s'il fonctionne — utilisez un espace de travail, qui ne modifie aucun fichier suivi :

```bash
cd turbo-go
go work init . ../turbo-core
```

[Tester sans publier](test-without-publishing.md) traite le sujet en détail : comment vérifier que c'est bien pris en compte, et comment tester la forme publiée une fois que vous êtes prêt.

### Le changement n'est pas rétrocompatible

Dites-le dans le message du tag et incrémentez la version mineure — le module est sous v1, donc l'incrément mineur est le signal disponible. Les éditeurs épinglent une version exacte : rien ne bouge tant que quelqu'un n'a pas modifié un `go.mod`.

### Vous devez déplacer un tag déjà poussé

Non. Plusieurs éditeurs peuvent l'épingler et le proxy de modules met en cache ce qu'il a récupéré : le script refuse. Incrémentez `TAG` à la place.

## Ce à quoi faire attention

Le script lance `make check`, et la suite qu'il lance contient des tests qui lancent *ce script* contre une copie jetable. Ils se sautent eux-mêmes quand `TURBO_CORE_RELEASING` est défini, ce que le script exporte avant d'appeler make. Retirer cette ligne fait récurser une publication jusqu'à épuisement de quelque chose.

## Voir aussi

- Publier un éditeur : le `how-to/make-a-release.md` de chaque éditeur
- Ce que couvrent les tests : [Lancer les tests](run-the-tests.md)