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