Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.0.5-alpha.6.fix.3

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-25 10:47:38 +02:00
parent b7e65d9100
commit 4e1c1cd6f0
7 changed files with 294 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
docs/rules/200-GOVERNANCE.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/200-GOVERNANCE.md -->
<!-- version: 3 -->
<!-- version: 4 -->
# Governance rules
@@ -38,9 +38,20 @@ Lorsqu'un dépôt utilise le fichier racine `VERSION`, ce fichier :
Un manifeste technique MAY refléter exactement `VERSION` lorsque son propre contrat l'exige. Un autre mécanisme de versioning MAY rester indépendant lorsqu'il possède une sémantique différente, par exemple un `versionCode` Android, une révision de document ou une version de protocole.
PGR MUST NOT imposer une égalité globale entre tous les champs contenant un numéro de version.
PGR MUST NOT imposer une égalité globale entre tous les champs contenant un numéro de version. Pour éviter à la fois les divergences silencieuses et le churn mécanique, chaque valeur de version durable SHOULD être classée selon son rôle réel. Les catégories réutilisables sont notamment :
Un champ de version qui n'est ni requis par l'écosystème ni utile au projet SHOULD être omis plutôt que maintenu comme duplication décorative.
- `CANONICAL` — identité SemVer exacte de l'unité de release, normalement portée par `VERSION` ;
- `MIRROR-EXACT` — miroir technique qui suit exactement `VERSION`, prereleases et fixes compris ;
- `MIRROR-STABLE` — miroir du jalon produit `X.Y.Z` ciblé, stable pendant `X.Y.Z-alpha.*`, `beta.*`, `rc.*` et leurs fixes ;
- `INDEPENDENT-COUNTER` — compteur technique monotone possédant sa propre sémantique ;
- `INDEPENDENT-SCHEMA` — version de protocole, format ou schéma indépendante du produit ;
- `DOCUMENT-REVISION` — révision interne d'un document ou artefact documentaire.
Seul un `MIRROR-EXACT` est normalement modifié à chaque changement de `VERSION`. Un `MIRROR-STABLE` SHOULD être fixé ou vérifié lorsque la cible `X.Y.Z` est ouverte, puis ne pas être réécrit uniquement parce qu'une tranche passe de `alpha.N` à `alpha.N+1`, à un `.fix.N`, à une beta ou à une RC. La promotion stable vérifie qu'il représente toujours la release publiée.
Lorsqu'une prerelease est réellement distribuée comme artefact installable distinct et que son écosystème exige une identité de package propre, le champ concerné peut devenir `MIRROR-EXACT` ou suivre des jalons explicitement définis. Cette décision appartient au plan de versioning/packaging du projet ; elle ne doit pas résulter d'une égalité globale implicite.
Un champ de version qui n'est ni requis par l'écosystème ni utile au projet SHOULD être omis plutôt que maintenu comme duplication décorative. Réciproquement, PGR MUST NOT imposer la suppression d'un champ utile uniquement pour éviter de le modifier à chaque prerelease : il faut d'abord lui attribuer la bonne classe de synchronisation.
## Schéma SemVer PGR