| 🛟 Updated. 28d5985 k33g 17h ago | 1 | # Comment publier la bibliothèque |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | 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. |
| 6 | |
| 7 | ## Étapes |
| 8 | |
| 9 | ### 1. Dire quelle version |
| 10 | |
| 11 | Créez `release.env` — il est ignoré par git, car un jeton de publication a aussi sa place dans un fichier de ce genre : |
| 12 | |
| 13 | ```sh |
| 14 | TAG="v0.1.0" |
| 15 | ABOUT="La bibliothèque des éditeurs Turbo" |
| 16 | ``` |
| 17 | |
| 18 | ### 2. Lancer le script |
| 19 | |
| 20 | ```bash |
| 21 | ./01-release.tag.sh |
| 22 | ``` |
| 23 | |
| 24 | 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. |
| 25 | |
| 26 | 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. |
| 27 | |
| 28 | ### 3. Créer la page de release |
| 29 | |
| 30 | Le tag suffit pour `go get` ; ceci ajoute la page qu'une personne lit. |
| 31 | |
| 32 | ```bash |
| 33 | ./02-release.publish.sh --dry-run # montre la requête, n'envoie rien |
| 34 | ./02-release.publish.sh # la crée |
| 35 | ``` |
| 36 | |
| 37 | 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`. |
| 38 | |
| 39 | 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. |
| 40 | |
| 41 | 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. |
| 42 | |
| 43 | ### 4. Y brancher les éditeurs |
| 44 | |
| 45 | Un éditeur à la fois, en lançant sa suite avant de passer au suivant : |
| 46 | |
| 47 | ```bash |
| 48 | go mod edit -require=codeberg.org/turbo-editors/turbo-core@v0.1.0 |
| 49 | go mod edit -dropreplace=codeberg.org/turbo-editors/turbo-core |
| 50 | go mod tidy |
| 51 | make test |
| 52 | ``` |
| 53 | |
| 54 | 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. |
| 55 | |
| 56 | ## Variantes |
| 57 | |
| 58 | ### Vous préférez le faire à la main |
| 59 | |
| 60 | ```bash |
| 61 | make check |
| 62 | git push origin main |
| 63 | git tag -a v0.1.0 -m "La bibliothèque des éditeurs Turbo" |
| 64 | git push origin v0.1.0 |
| 65 | ``` |
| 66 | |
| 67 | Poussez la branche **avant** le tag, pour la raison ci-dessus. |
| 68 | |
| 69 | ### Vous développez à travers les trois dépôts |
| 70 | |
| 71 | 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 : |
| 72 | |
| 73 | ```bash |
| 74 | cd turbo-go |
| 75 | go work init . ../turbo-core |
| 76 | ``` |
| 77 | |
| 78 | [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. |
| 79 | |
| 80 | ### Le changement n'est pas rétrocompatible |
| 81 | |
| 82 | 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`. |
| 83 | |
| 84 | ### Vous devez déplacer un tag déjà poussé |
| 85 | |
| 86 | 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. |
| 87 | |
| 88 | ## Ce à quoi faire attention |
| 89 | |
| 90 | 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. |
| 91 | |
| 92 | ## Voir aussi |
| 93 | |
| 94 | - Publier un éditeur : le `how-to/make-a-release.md` de chaque éditeur |
| 95 | - Ce que couvrent les tests : [Lancer les tests](run-the-tests.md) |