bots-garden/sidekicks · d13101a

modified .tickets/milestones.yaml +1 -1 Viewed

@@ -28,5 +28,5 @@ milestones:
28	28	state: closed
29	29	description: "Prévisualisation des fichiers, (re)création des sandboxes sbx et des containers, assistant de configuration des agents locaux (mm, docker-agent)."
30	30	- title: "v1.0.0 · Release"
31		- state: open
	31	+ state: closed
32	32	description: "Version, vérifications, packaging (macOS, Windows), tag v1.0.0 et publication de la release, avec ce qu'apportent M5 et les milestones précédentes."

      state: closed
      description: "Prévisualisation des fichiers, (re)création des sandboxes sbx et des containers, assistant de configuration des agents locaux (mm, docker-agent)."
    - title: "v1.0.0 · Release"
--    state: open
++    state: closed
      description: "Version, vérifications, packaging (macOS, Windows), tag v1.0.0 et publication de la release, avec ce qu'apportent M5 et les milestones précédentes."

modified RELEASING.fr.md +11 -1 Viewed

@@ -2,13 +2,14 @@
2	2
3	3	[English](RELEASING.md)
4	4
5		-Trois étapes, sur le Mac : tout construire, tagger, attacher les fichiers.
	5	+Trois étapes, sur le Mac : tout construire, tagger, attacher les fichiers ; puis ramener le tag dans chaque copie du dépôt.
6	6
7	7	\| Étape \| Commande \| Résultat \|
8	8	\| --- \| --- \| --- \|
9	9	\| 1. Construire \| `make release-build` \| `dist/` : les paquets macOS (Apple Silicon) et Windows (x86-64 et Arm), et `SHA256SUMS` \|
10	10	\| 2. Tagger \| `make release-tag` \| le tag `v<version>` est poussé ; le workflow Release crée la release sur Rickub, avec ses notes \|
11	11	\| 3. Attacher \| à la main, sur la page de la release \| tous les fichiers de `dist/` attachés à la release \|
	12	+\| 4. Après \| `git fetch --tags` \| le tag `v<version>` est dans chaque copie du dépôt \|
12	13
13	14	La version est `info.version` dans `build/config.yml` ; le tag est `v` + cette version.
14	15
@@ -48,6 +49,15 @@ Il refuse si la copie de travail a des modifications, si vous n'êtes pas sur `m
48	49
49	50	Ouvrez la release sur Rickub (Releases → v<version>) et attachez tous les fichiers de `dist/`, `SHA256SUMS` compris.
50	51
	52	+## 4. Après : récupérer le tag
	53	+
	54	+```bash
	55	+git fetch --tags
	56	+git tag --list 'v*' # v<version> apparaît
	57	+```
	58	+
	59	+Dans chaque autre copie du dépôt (une autre machine, une sandbox, un clone fait avant la release), récupérez les tags : le tag a été poussé depuis le Mac, un simple `git pull` ne le ramène pas toujours, et `git describe`, `git log v<précédente>..v<version>` ou les notes de la release suivante en ont besoin.
	60	+
51	61	## En cas de problème
52	62
53	63	\| Symptôme \| Que faire \|

  [English](RELEASING.md)
--Trois étapes, sur le Mac : tout construire, tagger, attacher les fichiers.
++Trois étapes, sur le Mac : tout construire, tagger, attacher les fichiers ; puis ramener le tag dans chaque copie du dépôt.
  | Étape | Commande | Résultat |
  | --- | --- | --- |
  | 1. Construire | `make release-build` | `dist/` : les paquets macOS (Apple Silicon) et Windows (x86-64 et Arm), et `SHA256SUMS` |
  | 2. Tagger | `make release-tag` | le tag `v<version>` est poussé ; le workflow **Release** crée la release sur Rickub, avec ses notes |
  | 3. Attacher | à la main, sur la page de la release | tous les fichiers de `dist/` attachés à la release |
++| 4. Après | `git fetch --tags` | le tag `v<version>` est dans chaque copie du dépôt |
  La version est `info.version` dans `build/config.yml` ; le tag est `v` + cette version.
  Ouvrez la release sur Rickub (**Releases → v<version>**) et attachez tous les fichiers de `dist/`, `SHA256SUMS` compris.
++## 4. Après : récupérer le tag
++
++```bash
++git fetch --tags
++git tag --list 'v*'      # v<version> apparaît
++```
++
++Dans chaque autre copie du dépôt (une autre machine, une sandbox, un clone fait avant la release), récupérez les tags : le tag a été poussé depuis le Mac, un simple `git pull` ne le ramène pas toujours, et `git describe`, `git log v<précédente>..v<version>` ou les notes de la release suivante en ont besoin.
++
  ## En cas de problème
  | Symptôme | Que faire |

modified RELEASING.md +11 -1 Viewed

@@ -2,13 +2,14 @@
2	2
3	3	[Français](RELEASING.fr.md)
4	4
5		-Three steps, on the Mac: build everything, tag, attach the files.
	5	+Three steps, on the Mac: build everything, tag, attach the files; then bring the tag back to every copy of the repository.
6	6
7	7	\| Step \| Command \| Result \|
8	8	\| --- \| --- \| --- \|
9	9	\| 1. Build \| `make release-build` \| `dist/`: the macOS (Apple Silicon) and Windows (x86-64 and Arm) packages, and `SHA256SUMS` \|
10	10	\| 2. Tag \| `make release-tag` \| the tag `v<version>` is pushed; the Release workflow creates the release on Rickub, with its notes \|
11	11	\| 3. Attach \| by hand, on the release page \| every file of `dist/` attached to the release \|
	12	+\| 4. After \| `git fetch --tags` \| the tag `v<version>` is in every copy of the repository \|
12	13
13	14	The version is `info.version` in `build/config.yml`; the tag is `v` + that version.
14	15
@@ -48,6 +49,15 @@ It refuses when the working tree has changes, when you are not on `main`, when `
48	49
49	50	Open the release on Rickub (Releases → v<version>), and attach every file of `dist/`, `SHA256SUMS` included.
50	51
	52	+## 4. After: fetch the tag
	53	+
	54	+```bash
	55	+git fetch --tags
	56	+git tag --list 'v*' # v<version> is listed
	57	+```
	58	+
	59	+In every other copy of the repository (another machine, a sandbox, a clone made before the release), fetch the tags: the tag was pushed from the Mac, a plain `git pull` does not always bring it, and `git describe`, `git log v<previous>..v<version>` or the next release's notes need it.
	60	+
51	61	## When something goes wrong
52	62
53	63	\| Symptom \| What to do \|

  [Français](RELEASING.fr.md)
--Three steps, on the Mac: build everything, tag, attach the files.
++Three steps, on the Mac: build everything, tag, attach the files; then bring the tag back to every copy of the repository.
  | Step | Command | Result |
  | --- | --- | --- |
  | 1. Build | `make release-build` | `dist/`: the macOS (Apple Silicon) and Windows (x86-64 and Arm) packages, and `SHA256SUMS` |
  | 2. Tag | `make release-tag` | the tag `v<version>` is pushed; the **Release** workflow creates the release on Rickub, with its notes |
  | 3. Attach | by hand, on the release page | every file of `dist/` attached to the release |
++| 4. After | `git fetch --tags` | the tag `v<version>` is in every copy of the repository |
  The version is `info.version` in `build/config.yml`; the tag is `v` + that version.
  Open the release on Rickub (**Releases → v<version>**), and attach every file of `dist/`, `SHA256SUMS` included.
++## 4. After: fetch the tag
++
++```bash
++git fetch --tags
++git tag --list 'v*'      # v<version> is listed
++```
++
++In every other copy of the repository (another machine, a sandbox, a clone made before the release), fetch the tags: the tag was pushed from the Mac, a plain `git pull` does not always bring it, and `git describe`, `git log v<previous>..v<version>` or the next release's notes need it.
++
  ## When something goes wrong
  | Symptom | What to do |

modified docs/en/how-to/publish-a-release.md +1 -0 Viewed

@@ -8,6 +8,7 @@ This guide shows how to publish a Sidekicks release from a Mac: build every pack
8	8	2. Build everything: `make release-build`. `dist/` then holds the macOS packages (`.dmg` and `.zip` for Apple Silicon), the Windows ones (installer and `.zip`, for x86-64 and for Arm) and `SHA256SUMS`.
9	9	3. Tag: `make release-tag`. The tag `v<version>` is pushed, and the Release workflow creates the release on Rickub with notes listing the files.
10	10	4. Attach the files: on Rickub, open Releases → v<version> and attach every file of `dist/`.
	11	+5. Fetch the tag in every other copy of the repository (another machine, a sandbox): `git fetch --tags`, then `git tag --list 'v*'` shows `v<version>`.
11	12
12	13	## Variants
13	14

 . **Build everything**: `make release-build`. `dist/` then holds the macOS packages (`.dmg` and `.zip` for Apple Silicon), the Windows ones (installer and `.zip`, for x86-64 and for Arm) and `SHA256SUMS`.
 . **Tag**: `make release-tag`. The tag `v<version>` is pushed, and the **Release** workflow creates the release on Rickub with notes listing the files.
 . **Attach the files**: on Rickub, open **Releases → v<version>** and attach every file of `dist/`.
++5. **Fetch the tag** in every other copy of the repository (another machine, a sandbox): `git fetch --tags`, then `git tag --list 'v*'` shows `v<version>`.
  ## Variants

modified docs/fr/how-to/publier-une-release.md +1 -0 Viewed

@@ -8,6 +8,7 @@ Ce guide montre comment publier une release de Sidekicks depuis un Mac : constru
8	8	2. Construisez tout : `make release-build`. `dist/` contient alors les paquets macOS (`.dmg` et `.zip` pour Apple Silicon), Windows (installateur et `.zip`, pour x86-64 et pour Arm) et `SHA256SUMS`.
9	9	3. Taggez : `make release-tag`. Le tag `v<version>` est poussé, et le workflow Release crée la release sur Rickub avec des notes qui listent les fichiers.
10	10	4. Attachez les fichiers : sur Rickub, ouvrez Releases → v<version> et attachez tous les fichiers de `dist/`.
	11	+5. Récupérez le tag dans chaque autre copie du dépôt (une autre machine, une sandbox) : `git fetch --tags`, puis `git tag --list 'v*'` affiche `v<version>`.
11	12
12	13	## Variantes
13	14

 . **Construisez tout** : `make release-build`. `dist/` contient alors les paquets macOS (`.dmg` et `.zip` pour Apple Silicon), Windows (installateur et `.zip`, pour x86-64 et pour Arm) et `SHA256SUMS`.
 . **Taggez** : `make release-tag`. Le tag `v<version>` est poussé, et le workflow **Release** crée la release sur Rickub avec des notes qui listent les fichiers.
 . **Attachez les fichiers** : sur Rickub, ouvrez **Releases → v<version>** et attachez tous les fichiers de `dist/`.
++5. **Récupérez le tag** dans chaque autre copie du dépôt (une autre machine, une sandbox) : `git fetch --tags`, puis `git tag --list 'v*'` affiche `v<version>`.
  ## Variantes

🛟 Updated.