0.1.2-alpha.1
This commit is contained in:
374
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
Normal file
374
docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md
Normal file
@@ -0,0 +1,374 @@
|
||||
<!-- file: docs/plans/008-V0_1_2_JAVA_GRADLE_REEVALUATION_PLAN.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Plan 0.1.2 — réévaluation Java / Maven / Gradle
|
||||
|
||||
## Statut et sources
|
||||
|
||||
Plan actif créé pendant `0.1.2-alpha.1` conformément à `prompts/008-V0_1_2_START_PROMPT.md`, après audit indépendant de la stable taggée `v0.1.1`, de son rapport post-tag `PASS` et du corpus Games autoritaire réellement fourni.
|
||||
|
||||
Sources autoritaires de reprise PGR :
|
||||
|
||||
```text
|
||||
pgr-v0.1.1(1).zip caaf8f456f7f8520172ea7705fd0cf5c5bf0e942dc4a773410bcbe7fe4ce243a
|
||||
pgr-0.1.1-publish.001-report(1).md 3eafc2767225526a6cba65b3b62a45a664b71a1f2fa049915ec243a196e14bb3
|
||||
```
|
||||
|
||||
Les noms locaux comportent `(1)`, mais l'archive PGR possède exactement le SHA-256 canonique enregistré par le rapport `publish.001`. Le rapport est `PASS`, porte sur cette même archive et confirme le commit stable `4893a04f4945f7cdc62d1294626a597353023a94`. Le tag annoté `v0.1.1` possède l'objet tag `09a3fe1501449a02a7edbbe9e897246b5434e15c` et se déréférence vers ce commit stable.
|
||||
|
||||
Corpus principal réellement fourni pour instruire Java/Gradle :
|
||||
|
||||
```text
|
||||
games-v0.3.6(1).zip ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8
|
||||
```
|
||||
|
||||
Le nom local comporte `(1)`, mais son SHA-256 correspond exactement à la baseline canonique `games-v0.3.6.zip` attendue par le prompt `008`. Games est donc le corpus autoritaire prévu pour cette réévaluation.
|
||||
|
||||
## Audit de la stable `v0.1.1`
|
||||
|
||||
### Intégrité de l'archive et preuve post-tag
|
||||
|
||||
L'archive stable contient `292` entrées sous une racine unique `pgr/`, soit `256` fichiers et `36` répertoires en comptant la racine. Son CRC est propre, aucun lien symbolique n'est présent et `.git` est absent comme attendu pour une archive de tag Gitea.
|
||||
|
||||
`VERSION` vaut exactement `0.1.1`. `CHANGELOG.md` contient l'entrée stable `0.1.1`, `ROADMAP.md` marque `0.1.1` terminé et conserve `0.1.2` à `0.1.7` engagés sans réserver `0.1.8`.
|
||||
|
||||
La publication observée suit le workflow courant :
|
||||
|
||||
```text
|
||||
tranche de clôture rel.1
|
||||
history rel.1 PASS
|
||||
commit stable 0.1.1
|
||||
tag v0.1.1
|
||||
publish.001 preuve externe post-tag PASS
|
||||
```
|
||||
|
||||
Le SHA de l'objet tag annoté reste distinct du commit stable ; la référence déréférencée pointe bien sur le même commit que `HEAD` et `origin/master` observés dans le rapport.
|
||||
|
||||
### Tests, audits et hygiène
|
||||
|
||||
Les quatre modules de tests Python de la stable ont été rejoués par groupes dans l'environnement d'analyse :
|
||||
|
||||
```text
|
||||
48 / 48 tests PASS
|
||||
```
|
||||
|
||||
Les audits documentaires donnent exactement :
|
||||
|
||||
```text
|
||||
Markdown header audit: clean (231 file(s))
|
||||
Markdown table audit: clean (9 table(s), 231 file(s))
|
||||
Markdown link audit: clean (267 local link(s), 231 file(s))
|
||||
```
|
||||
|
||||
Les cinq templates TOML Rust/Cargo restent parsables. Aucun symlink ni output courant tel que `target/`, `node_modules/`, `dist/` ou `__pycache__/` n'est embarqué dans la stable.
|
||||
|
||||
### Chaîne delta/history et vérité opérateur
|
||||
|
||||
Les `83` deltas publiés de `0.0.1` à `0.1.1` disposent tous d'un history portant la même identité.
|
||||
|
||||
Pour `0.1.1`, la vérité opérateur est conservée :
|
||||
|
||||
```text
|
||||
alpha.1 PASS
|
||||
alpha.2 FAIL
|
||||
alpha.2.fix.1 PASS
|
||||
alpha.3 PASS
|
||||
alpha.3.fix.1 FAIL
|
||||
alpha.3.fix.2 PASS
|
||||
alpha.4 PASS
|
||||
alpha.5 PASS
|
||||
beta.1 PASS
|
||||
rc.1 PASS
|
||||
rel.1 PASS
|
||||
```
|
||||
|
||||
Les `FAIL` ne sont ni écrasés ni réécrits après leurs corrections.
|
||||
|
||||
### État des owners et décisions différées
|
||||
|
||||
La stable possède notamment :
|
||||
|
||||
```text
|
||||
510 Rust / Cargo
|
||||
520 Java / Maven / Gradle
|
||||
530 TypeScript
|
||||
540 JavaScript package ecosystem
|
||||
550 Vite
|
||||
560 CSS / Sass
|
||||
610 Android
|
||||
710 Tauri 2
|
||||
```
|
||||
|
||||
La fondation Web `0.1.1` est stable et son skeleton est indépendant du host. Le skeleton Tauri reste `DEFER` jusqu'au réexamen réservé à `0.1.4` ; `0.1.2` n'a donc aucune raison de rouvrir cette décision.
|
||||
|
||||
Le profil `520-JAVA_MAVEN_GRADLE.md` est l'owner à réévaluer. Le profil `610-ANDROID.md` reste l'owner des contraintes Android et sert ici uniquement à contrôler la frontière de responsabilité, pas à démarrer `0.1.3`.
|
||||
|
||||
## Audit du corpus Games `0.3.6`
|
||||
|
||||
### Intégrité et portée
|
||||
|
||||
L'archive Games contient `652` entrées sous une racine unique `games/`, soit `502` fichiers et `150` répertoires. Son CRC est propre et aucun lien symbolique n'est présent.
|
||||
|
||||
La version produit est portée par `Cargo.toml` et vaut `0.3.6`. L'absence d'un fichier racine `VERSION` dans ce corpus n'est pas interprétée comme un défaut PGR : Games n'est pas encore dans sa release d'adoption `0.3.7` / PGR `0.1.5`.
|
||||
|
||||
Les audits statiques rejoués sur l'archive donnent :
|
||||
|
||||
```text
|
||||
General Rust rule audit: clean
|
||||
Rust export completeness audit: 0 candidate(s)
|
||||
games.sasedev workspace audit: clean
|
||||
Markdown table audit: clean (6 table(s), 319 file(s))
|
||||
Distribution layout audit: clean (55 required path(s), 11 forbidden path(s) absent)
|
||||
```
|
||||
|
||||
Ces contrôles attestent l'intégrité structurelle du corpus utilisé pour l'étude ; ils ne remplacent pas les validations Gradle/Android historiques déjà consignées par Games.
|
||||
|
||||
### Structure Java observée
|
||||
|
||||
Le corpus contient quatre sources Java, toutes sous la convention `src/main/java/` :
|
||||
|
||||
```text
|
||||
Android/common/src/main/java/com/sasedev/games/common/NativeBridge.java
|
||||
Android/common/src/main/java/com/sasedev/games/common/SaseGameActivity.java
|
||||
Android/game-reflex-poc/src/main/java/com/sasedev/games/reflex/ReflexActivity.java
|
||||
Android/game-snake-poc/src/main/java/com/sasedev/games/snake/SnakeActivity.java
|
||||
```
|
||||
|
||||
Les déclarations de package correspondent à leurs chemins. Les imports présents sont explicites ; aucun wildcard import n'est observé. La visibilité est bornée par la responsabilité des classes et les classes finales qui n'ont pas vocation à être étendues le sont effectivement.
|
||||
|
||||
Le corpus n'exerce pas de suite Java générique sous `src/test/java/`. Il ne fournit donc pas une preuve suffisante pour renforcer ou spécialiser les règles de tests Java du profil `520` au-delà de ce qui existe déjà.
|
||||
|
||||
Les responsabilités `Activity`, JNI, SDL3 et API Android rencontrées dans ces sources restent des responsabilités Android ou produit. Leur présence ne transforme pas ces contrats en règles Java générales.
|
||||
|
||||
### Build Gradle observé
|
||||
|
||||
Le projet Android est un build Gradle multi-module en Groovy DSL comprenant :
|
||||
|
||||
```text
|
||||
:common
|
||||
:game-reflex-poc
|
||||
:game-snake-poc
|
||||
```
|
||||
|
||||
L'ownership est réparti de manière identifiable :
|
||||
|
||||
- `settings.gradle` possède la composition des modules, la résolution des plugins/dépendances et le contrôle du minimum Gradle ;
|
||||
- le `build.gradle` root possède les versions des plugins appliqués aux sous-projets ;
|
||||
- `gradle.properties` porte des propriétés partagées non secrètes du build ;
|
||||
- chaque `build.gradle` de module porte sa configuration locale et ses dépendances ;
|
||||
- les scripts sous `Android/gradle/` portent une logique de build commune devenue suffisamment importante pour ne pas être dupliquée dans chaque module.
|
||||
|
||||
Cette répartition corrobore le principe PGR de centraliser ce qui est réellement commun sans imposer un layout ou une abstraction identique à tous les projets Gradle.
|
||||
|
||||
### JDK, niveau Java et compatibilité
|
||||
|
||||
L'historique Games fournit une preuve particulièrement utile pour la distinction déjà exigée par `520`.
|
||||
|
||||
Une première preuve `0.3.3-0-pre.2` a utilisé un Gradle Wrapper `9.6.0` et Temurin `17` via `JAVA_HOME`. Cette combinaison a ensuite été volontairement remplacée par un contrat moins restrictif : Gradle système `>= 9.6.0` et JDK courant de l'environnement.
|
||||
|
||||
Les gates `0-pre.3` à `0-pre.5` ont validé :
|
||||
|
||||
```text
|
||||
JDK de build Temurin 25.0.4.1 LTS
|
||||
Gradle exécuté 9.7.1
|
||||
niveau Java source/target 17
|
||||
```
|
||||
|
||||
La preuve démontre qu'un JDK de build plus récent peut exécuter la toolchain tout en produisant un code Java ciblant un niveau plus ancien explicitement déclaré. Elle ne justifie ni d'imposer Java 17 à PGR, ni d'imposer JDK 25, ni de transformer une contrainte Android en règle Java générale.
|
||||
|
||||
### Gradle système versus Wrapper
|
||||
|
||||
La trajectoire Games est utile précisément parce qu'elle a exercé les deux politiques :
|
||||
|
||||
1. wrapper exact introduit pour une preuve bornée et reproductible ;
|
||||
2. retrait du wrapper lorsque la décision durable est devenue « Gradle système compatible, minimum vérifié » ;
|
||||
3. contrôle de `GradleVersion.current()` contre `9.6.0` dans `settings.gradle` ;
|
||||
4. validation réelle avec Gradle `9.7.1`.
|
||||
|
||||
Cette trajectoire confirme qu'un Wrapper est un moyen de reproductibilité, pas une obligation cérémonielle, et qu'un Gradle système peut être une politique durable lorsque sa contrainte est explicitement vérifiée.
|
||||
|
||||
Le minimum exact `9.6.0` est toutefois lié à la stack Android observée et reste hors de toute règle Gradle générale.
|
||||
|
||||
### DSL, dépendances et versions
|
||||
|
||||
Games utilise uniquement le Groovy DSL pour son projet Gradle natif. Ce choix ne fournit aucune preuve permettant de rendre Groovy obligatoire ou de déprécier Kotlin DSL dans PGR.
|
||||
|
||||
Aucun version catalog n'est présent. Les versions de plugins réellement partagées sont centralisées au root ; les repositories sont possédés au niveau `settings.gradle`. Cette organisation confirme la valeur de l'ownership partagé mais ne justifie pas d'imposer `libs.versions.toml`, `RepositoriesMode.FAIL_ON_PROJECT_REPOS` ou un repository particulier à tous les builds Gradle.
|
||||
|
||||
Aucun projet Maven, `pom.xml` ou Maven Wrapper n'est présent. Games n'autorise donc aucun nouvel artefact Maven dans `0.1.2` ; les règles Maven existantes seront seulement relues pour cohérence avec le contrat général du profil.
|
||||
|
||||
### Outputs, état local et validation
|
||||
|
||||
La stable Games ignore explicitement les caches et outputs Gradle :
|
||||
|
||||
```text
|
||||
/Android/.gradle/
|
||||
/Android/**/build/
|
||||
```
|
||||
|
||||
`local.properties` reste également hors Git. Cette pratique corrobore la séparation PGR entre configuration partagée versionnée, état machine local et outputs générés.
|
||||
|
||||
Les gates historiques utilisent directement les tâches Gradle pertinentes (`assembleDebug`, `bundleRelease`, etc.) et n'emploient `clean` que lorsqu'une phase de stabilisation a réellement besoin de reconstruire depuis un état nettoyé. Cela confirme le principe PGR : tâches ciblées pendant le développement, gates plus larges lorsque le scope ou la phase le justifie, et aucun `clean` systématique comme pseudo-preuve.
|
||||
|
||||
## Frontière Android obligatoire
|
||||
|
||||
Les éléments suivants sont observés dans Games mais appartiennent explicitement à `610-ANDROID.md`, à une spécialisation Android/Rust/JNI ou au produit Games :
|
||||
|
||||
```text
|
||||
AGP 9.4.0
|
||||
compileSdk / targetSdk / minSdk
|
||||
NDK et ABI Android
|
||||
AAR SDL3 et Prefab
|
||||
JNI et bibliothèques natives
|
||||
applicationId / namespace / manifests / resources
|
||||
APK / AAB / signing
|
||||
Variant API Android
|
||||
AVD, devices et smokes Android
|
||||
contraintes 16 KB
|
||||
choix SDL3 et architecture des jeux
|
||||
```
|
||||
|
||||
Aucun de ces éléments ne doit devenir une règle Java/Gradle générale pendant `0.1.2`.
|
||||
|
||||
Une contrainte Gradle ou JDK plus étroite imposée par AGP constitue un raffinement de plateforme. `0.1.2` peut documenter cette frontière dans `520`, mais ne réécrit pas le profil Android et ne commence pas `0.1.3`.
|
||||
|
||||
## Classification initiale des décisions Games
|
||||
|
||||
La classification suivante guide les tranches normatives ; elle ne constitue pas encore une adoption de Games, réservée à `0.1.5`.
|
||||
|
||||
| Décision observée | Classification | Traitement `0.1.2` |
|
||||
|--------------------------------------------------------------------------------|----------------------------------|--------------------------------------------------------------------------------------------|
|
||||
| Séparer JDK de build et niveau Java produit | `ADOPT` | conserver et clarifier dans `520` |
|
||||
| Utiliser la structure Java canonique `src/main/java` et des packages cohérents | `ADOPT` | conserver les règles existantes, sans importer les responsabilités Android |
|
||||
| Centraliser la configuration Gradle réellement commune | `ADOPT` | préciser les owners `settings` / root / sous-projets sans imposer le layout Games |
|
||||
| Gradle système avec contrainte minimale effectivement vérifiée | `ADOPT` comme politique possible | renforcer le contrat de vérifiabilité, sans imposer `9.6.0` |
|
||||
| Absence durable de Gradle Wrapper dans Games | `KEEP-LOCAL` | conserver le Wrapper comme option PGR de reproductibilité, pas comme obligation |
|
||||
| Groovy DSL | `KEEP-LOCAL` | maintenir Groovy et Kotlin DSL comme choix valides ; ne pas copier la préférence Games |
|
||||
| JDK 25 LTS de build et source/target 17 | `KEEP-LOCAL` | ne généraliser que leur séparation conceptuelle |
|
||||
| Matrice AGP/Gradle/JDK plus étroite | `OVERRIDE` de plateforme | reste possédée par `610` / Android, hors normalisation `520` |
|
||||
| Version catalog | `DEFER` | aucun besoin démontré ; rester optionnel |
|
||||
| Nouveaux templates/audits Maven | `DEFER` | aucun corpus Maven réel fourni |
|
||||
| Skeleton Java/Gradle générique | `DEFER` | Games n'exerce qu'un build Gradle Android ; preuve insuffisante pour un skeleton générique |
|
||||
| Audit Python Java/Gradle | `DEFER` | aucune propriété générique non mieux contrôlée par Java/Gradle n'est encore démontrée |
|
||||
|
||||
## Réévaluation du profil `520`
|
||||
|
||||
Le profil existant est globalement cohérent avec les preuves Games : il distingue déjà JDK de build et niveau Java, rend les Wrappers conditionnels, reconnaît Gradle système, accepte Groovy/Kotlin DSL, déconseille `clean` systématique et ignore les outputs/caches.
|
||||
|
||||
La release doit donc privilégier une correction ciblée plutôt qu'une réécriture. Les points à instruire en priorité sont :
|
||||
|
||||
1. préciser que la compatibilité Java ne se résume pas au JDK actif et qu'un JDK de build plus récent peut cibler un niveau produit plus ancien explicitement déclaré ;
|
||||
2. rendre explicite qu'une politique « Gradle système » doit posséder une contrainte vérifiable par le build ou la gate, pas seulement une version écrite dans une documentation ;
|
||||
3. préciser les responsabilités naturelles de `settings.gradle(.kts)`, du root build et des sous-projets sans transformer les APIs modernes observées dans Games en obligations universelles ;
|
||||
4. distinguer `gradle.properties` partagé et portable des propriétés locales, chemins machine, secrets ou overrides utilisateur ;
|
||||
5. conserver la neutralité Groovy/Kotlin DSL et le caractère conditionnel du Wrapper/version catalog ;
|
||||
6. relire les sections Maven pour cohérence, sans créer de nouvel artefact Maven faute de corpus ;
|
||||
7. vérifier qu'aucune règle Java/Gradle n'absorbe AGP, SDK, NDK, ABI/JNI, packaging ou smokes Android.
|
||||
|
||||
Le regroupement actuel Java/Maven/Gradle dans un seul owner est également relu au regard de `500-LANGUAGES.md`. Une scission documentaire ne sera effectuée que si elle réduit réellement les responsabilités ambiguës. En l'absence de corpus Maven, `0.1.2` ne créera pas artificiellement un nouvel owner Maven uniquement pour satisfaire une préférence de découpage.
|
||||
|
||||
## Mission de `0.1.2`
|
||||
|
||||
La release doit produire un profil Java/Maven/Gradle mieux éprouvé par une implémentation réelle tout en restant générique.
|
||||
|
||||
Elle MUST :
|
||||
|
||||
- conserver les choix Java/Gradle qui sont déjà correctement généralisés ;
|
||||
- corriger uniquement les ambiguïtés ou lacunes démontrées par Games ;
|
||||
- classer les contraintes Android comme overrides de plateforme plutôt que règles générales ;
|
||||
- utiliser Java/Gradle eux-mêmes comme autorité lorsqu'une validation exécutable est nécessaire ;
|
||||
- conserver Maven cohérent sans inventer de template, audit ou skeleton en l'absence de corpus Maven ;
|
||||
- ne créer un nouvel artefact Java/Gradle que s'il évite une duplication réelle ou matérialise un contrat absent du profil actuel.
|
||||
|
||||
Elle MUST NOT :
|
||||
|
||||
- modifier Games ;
|
||||
- démarrer l'adoption Games `0.1.5` ;
|
||||
- réécrire `610-ANDROID.md` ou commencer `0.1.3` ;
|
||||
- créer ou réexaminer le skeleton Tauri avant `0.1.4` ;
|
||||
- rouvrir les owners Web `530` à `560` sans défaut transversal démontré ;
|
||||
- introduire Maven, Kotlin DSL, version catalog, Wrapper ou plugin par simple possibilité écosystème.
|
||||
|
||||
## Artefacts candidats
|
||||
|
||||
Artefact certain :
|
||||
|
||||
```text
|
||||
docs/rules/520-JAVA_MAVEN_GRADLE.md révision ciblée si alpha.2 confirme les précisions ci-dessus
|
||||
```
|
||||
|
||||
Artefacts conditionnels seulement si une lacune réelle apparaît pendant la révision :
|
||||
|
||||
```text
|
||||
docs/validation/... uniquement si les commandes déjà présentes dans 520 sont insuffisantes comme contrat réutilisable
|
||||
docs/templates/... uniquement si un fichier générique possède assez de décisions stables pour être adapté sans copier Android
|
||||
scripts/audit_*.py uniquement pour une propriété statique générique non déjà contrôlée par Java/Gradle
|
||||
```
|
||||
|
||||
Aucun skeleton Java/Gradle ni artefact Maven nouveau n'est prévu par défaut.
|
||||
|
||||
## Trajectoire prévisionnelle de `0.1.2`
|
||||
|
||||
### alpha.1 — audit de stable, corpus et plan
|
||||
|
||||
Vérifier `v0.1.1`, son rapport `publish.001`, le corpus Games, la frontière Android et la classification initiale. Créer le présent plan sans modifier encore `520` ou `610`.
|
||||
|
||||
### alpha.2 — révision ciblée Java / Gradle
|
||||
|
||||
Réviser `520-JAVA_MAVEN_GRADLE.md` uniquement sur les points réellement démontrés : compatibilité JDK/source/bytecode, ownership Gradle, contrainte système vérifiable, Wrapper conditionnel, DSL, propriétés partagées/locales, validation et outputs.
|
||||
|
||||
Relire les sections Maven pour cohérence sans ajouter d'artefact Maven. Conserver toutes les contraintes Android dans leur owner actuel.
|
||||
|
||||
### beta.1 — réconciliation et décision d'artefacts
|
||||
|
||||
Relire le profil révisé contre Games, `500-LANGUAGES.md`, `610-ANDROID.md` et les règles générales de validation. Vérifier qu'aucun choix local Games ou contrainte Android n'est devenu un `MUST` général.
|
||||
|
||||
À ce stade seulement, décider si un contrat de validation, template ou audit générique supplémentaire apporte une valeur réelle. S'il n'en apporte pas, consigner explicitement qu'aucun artefact supplémentaire n'est nécessaire plutôt que créer une tranche décorative.
|
||||
|
||||
La beta met également à jour les index/documentation durable nécessaires à la release et prépare la clôture sans ouvrir `0.1.3` prématurément.
|
||||
|
||||
### rc.1 — release candidate
|
||||
|
||||
Geler le scope, rejouer la validation PGR complète, contrôler les liens/index, la frontière Android, l'absence d'artefacts Maven non justifiés et la cohérence de la trajectoire `0.1.3` à `0.1.7`.
|
||||
|
||||
Aucune nouvelle règle fonctionnelle n'entre en RC sauf correctif `.fix.N` ou REPLAN explicitement justifié.
|
||||
|
||||
### rel.1 — promotion stable
|
||||
|
||||
Promouvoir mécaniquement la RC validée vers `0.1.2`, fermer le plan, mettre à jour `CHANGELOG.md` et `ROADMAP.md` selon le workflow applicable, préparer le handoff de publication et conserver la prochaine cible engagée `0.1.3` sans l'exécuter avant vérification post-tag de `0.1.2`.
|
||||
|
||||
## Stratégie de validation
|
||||
|
||||
`alpha.1` reste documentaire et structurel : tests Python PGR, audits Markdown, contrôle des couples delta/history, vérification du prompt `008`, de `520`, de `610`, du plan et du scope Git.
|
||||
|
||||
Lorsqu'une tranche modifie uniquement des règles PGR et ne contient aucun projet Java/Gradle exécutable, PGR ne doit pas simuler un build Java. Les preuves Games historiques peuvent justifier une décision, mais elles ne deviennent pas une gate opérateur PGR locale.
|
||||
|
||||
Si une tranche ultérieure ajoute un artefact Gradle exécutable réel, sa validation doit utiliser Java/Gradle officiels en plus des audits PGR applicables. Un audit Python ne remplacera ni `javac`, ni Gradle, ni Maven.
|
||||
|
||||
La validation reste proportionnée : aucune commande `clean` systématique et aucune gate Android uniquement parce que Games a servi de corpus d'étude.
|
||||
|
||||
## Déclencheurs de REPLAN
|
||||
|
||||
Un REPLAN est requis notamment si :
|
||||
|
||||
- la révision montre que `520` doit être scindé en plusieurs owners pour éviter une ambiguïté normative réelle ;
|
||||
- un besoin Maven réel apparaît et exige un corpus ou une preuve absente de la baseline actuelle ;
|
||||
- une modification supposée générique dépend en réalité d'AGP, du SDK/NDK, de JNI ou du packaging Android ;
|
||||
- un template/audit candidat exige de copier une structure Games plutôt que de matérialiser un contrat réutilisable ;
|
||||
- la release ne peut pas rester bornée sans absorber une responsabilité explicitement réservée à `0.1.3` ou `0.1.4`.
|
||||
|
||||
Un REPLAN ne sert pas à ajouter des artefacts pour remplir la release ; il sert à corriger son découpage lorsque les owners réels l'exigent.
|
||||
|
||||
## Clôture et transition
|
||||
|
||||
La réconciliation documentaire durable, le `CHANGELOG`, la mise à jour de `ROADMAP`, la fermeture du plan et la préparation de la publication sont traités en beta/RC/`rel.1` selon l'état réel de la release.
|
||||
|
||||
La roadmap possède déjà un horizon suffisant jusqu'à `0.1.7`. Aucune nouvelle revue d'horizon n'est requise par défaut pendant `0.1.2`.
|
||||
|
||||
La prochaine release engagée après publication vérifiée de `0.1.2` reste :
|
||||
|
||||
```text
|
||||
0.1.3 — réévaluation pratique du profil Android à partir de Games
|
||||
```
|
||||
|
||||
Le prompt de démarrage de `0.1.3` ne doit être préparé que dans une tranche où la clôture `0.1.2` est suffisamment déterminée, puis exécuté seulement après stable taggée et preuve post-tag applicable.
|
||||
Reference in New Issue
Block a user