4.0 KiB
Règles de profils plateforme
Scope
Cette famille définit le contrat commun des profils liés à une plateforme de build, d'exécution ou de distribution telle qu'Android, iOS, Desktop, Web ou une cible embarquée lorsqu'un profil réel le justifie.
Les règles propres à une plateforme sont ajoutées dans des documents plus spécifiques uniquement lorsqu'elles possèdent un contenu normatif réel.
Responsabilités de la famille
Un profil plateforme MAY posséder les règles spécifiques concernant notamment :
- la structure de projet imposée ou conventionnelle sur cette plateforme ;
- les SDKs, targets, runtimes et niveaux minimums supportés ;
- les contraintes de toolchain réellement imposées par la plateforme ;
- les permissions, manifests, capabilities ou métadonnées de plateforme ;
- le packaging, la signature et les artefacts de distribution ;
- les émulateurs, simulateurs, appareils ou environnements nécessaires aux smokes ;
- les adaptations de lifecycle, input ou services réellement propres à la plateforme ;
- les contraintes de compatibilité utilisateur liées à une version minimale de target/runtime.
Un profil plateforme MUST NOT recopier les règles du langage ou du build tool lorsque celles-ci restent valides sans spécialisation.
Composition avec les langages et build tools
Une plateforme peut être utilisée avec plusieurs langages ou toolchains. Son profil ne doit donc pas supposer implicitement une combinaison unique lorsque la plateforme elle-même ne l'impose pas.
Lorsqu'une plateforme impose une contrainte plus précise à un langage ou build tool déjà applicable, la règle plateforme peut la raffiner ou la remplacer dans son scope à condition d'identifier clairement la contrainte et sa raison.
Cette contrainte MUST NOT se propager aux projets utilisant le même langage hors de cette plateforme.
Toolchain de build et compatibilité de target
La modernité de la toolchain de build et la version minimale du runtime ou de la target sont deux décisions distinctes.
L'utilisation d'un SDK, compilateur ou build tool récent ne justifie pas à elle seule l'augmentation de la version minimale supportée par les utilisateurs.
Une hausse d'un minimum de target/runtime constitue un changement de compatibilité et doit être justifiée par une contrainte ou un bénéfice réel du projet.
Inversement, un minimum ancien ne doit pas être conservé artificiellement lorsqu'il empêche une capacité nécessaire, une maintenance raisonnable ou une chaîne de build supportée.
Packaging, secrets et configuration locale
Les règles de packaging ou de signature spécifiques à une plateforme peuvent appartenir à son profil, mais les secrets eux-mêmes restent soumis aux règles générales PGR et ne sont jamais versionnés.
Une plateforme peut nécessiter des fichiers locaux ou générés particuliers ; leur politique Git doit être documentée dans le profil spécifique seulement lorsqu'elle diffère réellement du contrat général.
Validation spécialisée
Un profil plateforme peut définir les builds, packages et smokes réellement nécessaires pour prouver le support annoncé.
La présence d'une plateforme dans un projet ne rend pas automatiquement tous ses smokes obligatoires à chaque tranche. La sélection reste proportionnée au scope modifié et aux preuves invalidées.
Les validations nécessitant un appareil, un simulateur, un service externe ou une chaîne de packaging réelle doivent être distinguées des contrôles documentaires ou unitaires qui ne prouvent pas ces comportements.
Nomenclature documentaire
Le document 600-PLATFORMS.md possède le contrat commun de la famille.
Les profils spécifiques utilisent la plage 610 à 699. Leur numéro sert à la navigation et ne détermine pas une priorité normative implicite.
La résolution entre profils suit ../architecture/003-RULE_PROFILE_MODEL.md.