Politique d'ingénierie de publication
Cinq politiques canoniques pour le versionnage, l'étiquetage des publications, les cycles d'obsolescence, les changements incompatibles et les procédures de retour arrière.
Cinq politiques régissent la façon dont apothem est publié.
1. Versionnage sémantique
Le projet est distribué sous Versionnage sémantique 2.0.
Les numéros de version prennent la forme MAJOR.MINOR.PATCH[-PRERELEASE][+BUILD].
| Incrément | Déclencheurs |
|---|---|
| MAJOR | Changements incompatibles dans les schémas d'artefacts, les identifiants de mandat (CM-N / TM-N / CP-N) ou les contrats de hooks |
| MINOR | Nouvelles règles, travailleurs délégués, commandes, compétences, événements de hook ou extensions de schéma non incompatibles |
| PATCH | Clarifications, ajouts d'anti-modèles, corrections de documentation et modifications qui ne changent pas le comportement |
Les étiquettes candidates utilisent le format vX.Y.Z-rc.N (candidate à la publication)
ou vX.Y.Z-alpha.N / vX.Y.Z-beta.N (accès anticipé).
2. Étiquettes de publication
Chaque publication dépose sur main une étiquette git signée de la forme
vMAJOR.MINOR.PATCH. L'étiquette déclenche .github/workflows/release.yml, qui
construit, signe, génère le SBOM et la provenance SLSA-3, et
publie la page GitHub Release.
Conventions d'étiquetage :
- Format — exactement
vMAJOR.MINOR.PATCH. Pas de préfixerelease-, pas de suffixe-final. - Annotation — chaque étiquette est une étiquette annotée (
git tag -a -s) portant le résumé des notes de publication dans le message de l'étiquette. - Signature — chaque étiquette est signée avec GPG. Le flux de travail de publication produit en outre une signature cosign sans clé Sigstore sur chaque artefact et une preuve de provenance de publication SLSA-3, toutes deux jointes à la page GitHub Release.
3. Politique d'obsolescence
La ligne de support public actuelle est la dernière version mineure publiée. Lorsque le projet comporte plusieurs versions mineures publiques, la matrice des versions prises en charge de SECURITY.md fait foi pour toute fenêtre de support supplémentaire limitée aux correctifs critiques.
Cadence d'obsolescence :
- Annonce — un symbole ou un comportement obsolète est
annoncé dans la section
### DeprecatedduCHANGELOG.mdde la publication dans laquelle l'obsolescence intervient. Les notes de publication reflètent l'annonce d'obsolescence. - Fenêtre de grâce — les symboles obsolètes restent disponibles pendant au minimum un cycle mineur complet avant leur suppression.
- Suppression — la suppression intervient lors d'un incrément
MAJOR. Chaque symbole supprimé porte une ligne### RemoveddansCHANGELOG.mdet une entrée de guide de migration sous Guides pratiques.
4. Politique de changements incompatibles
Les changements incompatibles exigent :
- Un ticket RFC — ouvert avec l'étiquette de ticket
rfcsdécrivant le changement incompatible, le chemin de migration et la stratégie de retour arrière. - Une fenêtre de commentaires de 30 jours — la RFC reste ouverte pendant au moins 30 jours avant la fusion. Les mainteneurs peuvent prolonger la fenêtre lorsque les retours le justifient.
- Un incrément MAJOR — la publication qui introduit le changement incompatible incrémente le composant MAJOR.
- Un guide de migration — le changement est livré avec une entrée de Guides pratiques qui guide l'opérateur tout au long de la migration.
5. Politique de retour arrière
Si une publication présente une régression qui bloque l'adoption :
- Annuler — le ou les commits fautifs sont annulés sur
main. - Réétiquetage version-plus-un — une publication de suivi intervient sous
vMAJOR.MINOR.PATCH+1portant l'annulation plus toute correction incrémentale. La précédente publication défectueuse n'est pas supprimée de GitHub Releases — une annotation### YankeddansCHANGELOG.mddocumente la situation afin que les compilations reproductibles restent ancrées. - Communication — un avis security-advisories (lorsqu'il est pertinent pour la sécurité) ou une publication Discussions (lorsqu'elle est pertinente pour la fiabilité) accompagne le retour arrière.
Voir aussi
- CHANGELOG.md — le registre canonique des publications.
- SECURITY.md — la matrice des versions prises en charge et les canaux de signalement.
- cicd-pipeline.md — les classes de vérifications CI qui contrôlent chaque publication.
- deployment-checklist.md — le balayage de préparation à la production par publication.
Registre de conformité externe — Lors d'opérations sur des projets hôtes
Registre de quinze mandats (M1–M15) spécifiant les exigences de conformité pour tous les artefacts générés dans les projets hôtes, croisé avec les mandats internes à l'écosystème.
Politique des badges
Spécifier les sources de badges dynamiques et statiques pour le README, couvrant le statut de workflow natif GitHub, le JSON d'endpoint shields.io et les formes de badge statique.