docs: align the branch model with the actual remote

Two points the document got wrong. The stable branch is main, not
master: the remote has never had a master. And the promotion chain was
written as if it existed, while landing-silo and experimental-silo were
created only today, the first as empty branches off main.

Nothing else in the document is touched.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Patrick Schurig 2026-08-02 10:29:32 +02:00
parent f839f5d435
commit 0cdcfe433b

View File

@ -24,13 +24,18 @@ amont.
## Branches et canaux
```
feature/* ──► landing-silo ──► experimental-silo ──► master
feature/* ──► landing-silo ──► experimental-silo ──► main
(nightly) (testing) (stable)
```
Vers la droite on promeut, vers la gauche on redescend un correctif. Une correction ne saute
jamais un cran.
Les trois branches existent sur le remote depuis le 2026-08-02. Les deux silos ont été créés
vides depuis `main` ; `landing-silo` a ensuite reçu `feature/fronius-sunspec` comme premier
contenu, `experimental-silo` est encore au niveau de `main`. Avant cette date le modèle
ci-dessus était une intention, pas un état du dépôt.
`experimental-silo` n'est pas une branche de travail : elle ne reçoit que ce qui a déjà survécu au
nightly. Le travail se fait dans `feature/*`.
@ -41,19 +46,19 @@ nightly. Le travail se fait dans `feature/*`.
| commits dans `feature/*` | `verify` en local, l'agent boucle seul |
| `feature/*` → `landing-silo` | PR, `verify` vert sur le runner, AC de la spec couverts par des tests |
| `landing-silo` → `experimental-silo` | build complet propre, banc nocturne vert |
| `experimental-silo` → `master` | validation matérielle nommée : appareil, firmware, configuration |
| `experimental-silo` → `main` | validation matérielle nommée : appareil, firmware, configuration |
Le dernier critère n'est pas automatisable et ne doit pas l'être.
### Correctifs
**Avant de créer une branche : reproduire le bug et déterminer la branche la plus proche de
`master` où il apparaît.** C'est elle qui décide du point de départ, pas l'urgence ressentie.
`main` où il apparaît.** C'est elle qui décide du point de départ, pas l'urgence ressentie.
| Le bug se reproduit… | Départ | Ensuite |
|---|---|---|
| jusque dans `master` | `hotfix/*` depuis `master` | fusion dans `master`, puis redescente dans `experimental-silo`, puis dans `landing-silo` |
| dans `experimental-silo`, pas dans `master` | `fix/*` depuis `experimental-silo` | redescente dans `landing-silo` |
| jusque dans `main` | `hotfix/*` depuis `main` | fusion dans `main`, puis redescente dans `experimental-silo`, puis dans `landing-silo` |
| dans `experimental-silo`, pas dans `main` | `fix/*` depuis `experimental-silo` | redescente dans `landing-silo` |
| seulement dans `landing-silo` | `fix/*` depuis `landing-silo` | rien, il remonte par la promotion normale |
Ne jamais corriger en aval un bug présent en amont : le correctif remontera un jour, mais la
@ -79,7 +84,7 @@ Ne jamais le remplacer par un tiret (`-etmN`) : `-` a un sens réservé en versi
## Agents
Les agents travaillent dans `feature/*` et `fix/*`. Jamais de commit direct dans `landing-silo`,
`experimental-silo` ou `master` : ces branches ne reçoivent que des fusions.
`experimental-silo` ou `main` : ces branches ne reçoivent que des fusions.
Une spec, une branche, un jeu de critères d'acceptation.
@ -90,7 +95,7 @@ fait pas.
1. **NE PAS renommer les paquets PUBLIÉS** : `powersync-plugin-eastron`,
`powersync-plugin-abbb2x`, `nymea-plugin-abbterra`. Casse l'upgrade des box beta.
Valable sur toutes les branches : un renommage dans `landing-silo` finit par atteindre `master`.
Valable sur toutes les branches : un renommage dans `landing-silo` finit par atteindre `main`.
2. `abbterra` est volontairement sous nom amont (transition upstream propre) — ne pas « corriger ».
3. Matrice validée beta : SDM72 / SDM120 (eastron), Waveshare D8.
4. Aucun composant propriétaire ici. Aucun ne doit y entrer.