turbo-editors/turbo-corepublic Fork 0
28d59854361aeda8541d853093e732126f3d7bff
Commits
Clone
git clone https://git.rickub.com/turbo-editors/turbo-core.git
git clone ssh://git@rickub.com/turbo-editors/turbo-core.git

Host key fingerprint (ed25519): SHA256:iycHnxEyq0Q7uyVpB7JlznP0G7JrTPXLYRcAU5CSLhc — verify it before your first connect.

🛟 Updated. 28d5985 · on 28d59854361aeda8541d853093e732126f3d7bff · k33g · 15h ago
release-the-library.md · 95 lines · 4.1 KBmarkdown
Blame HistoryOpen raw

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 :

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

2. Lancer le script

./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.

./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 :

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

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 :

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

Tester sans publier 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
 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
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
# 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)