Préparation de release QF_solver 0.2.2a0¶

Objet¶

Cette fiche trace la préparation du tag v0.2.2a0, la construction des distributions et la publication PyPI. Le commit de release et le tag sont désormais gelés et poussés ; la disponibilité PyPI reste conditionnée au workflow GitHub et à ses gates. La décision de release reste distincte de la revue Owner du backend numérique.

État actuel¶

Point	État	Observation
Version package	`READY`	`pyproject.toml`, `src/solveur/version.py` et README ciblent `0.2.2a0`
Changelog	`READY`	section `0.2.2a0` ajoutée avec les limites connues
Citation	`READY`	version logicielle et date alignées sur `0.2.2-alpha`
Licence	`READY`	Apache-2.0 pour le code, CC BY 4.0 pour la documentation et les exemples originaux
API publique	`READY`	contrat `from qf_solver import ...` vérifié
Couverture CI	`PASS`	gate `80 %`, campagne locale à `88,67 %`
Audit public	`PASS`	`qualification/publication_audit_0_2_2.json`, `1763` fichiers, zéro finding
Backend V&V	`PASS_BOUNDED`	périmètre borné, revue Owner `accepted_with_recommendations`
Tag Git	`PUSHED`	`v0.2.2a0` sur le commit `c54f4b6`
Publication PyPI	`IN_PROGRESS`	workflow GitHub déclenché par le tag ; disponibilité externe à confirmer

Contrôles locaux avant tag¶

Les commandes suivantes sont à exécuter sur le commit candidat, après revue des fichiers suivis. Elles ne doivent pas être remplacées par une publication manuelle depuis un répertoire de travail non inspecté.

python -m build
python -m twine check dist/*
python scripts/check_distribution.py dist/*
python scripts/audit_public_release.py --output qualification/publication_audit_0_2_2.json
python scripts/audit_git_history.py --output git_history_audit.json
python scripts/audit_release_archive.py --ref HEAD --output release_archive_audit.json
python scripts/release_readiness.py --output release_readiness.json

Le résultat attendu est DISTRIBUTION CHECK: PASS pour wheel et sdist, un audit public PASS sans finding, puis READY pour release_readiness.py. Avant le tag, release_readiness.py peut rester NOT_READY à cause du worktree modifié et de l'absence de tag : ce sont des contrôles de gel, pas des erreurs du package.

Contenu attendu des distributions¶

La wheel doit contenir le runtime qf_solver/ et solveur/, sans tests, scripts, outils ni corpus V&V de travail. Le sdist doit contenir le README, la licence et les sources src/solveur/. Les exemples et registres déclarés dans pyproject.toml doivent rester lisibles après installation.

Après construction, vérifier localement :

python -m pip install --force-reinstall dist/qf_solver-0.2.2a0-py3-none-any.whl
qf-solver --version
qf-solver methods
python -c "from qf_solver import solve_model; print(solve_model.__name__)"

Tag créé et poussé¶

Le contenu staged a été validé, puis le tag a été créé après confirmation Owner de la release :

git status --short
git diff --cached --check
git diff --cached --name-only
git tag -a v0.2.2a0 -m "Release QF_solver 0.2.2a0"

Après création du tag, rejouer l'audit d'archive avec les attributs commités :

python scripts/audit_release_archive.py --ref v0.2.2a0 --committed-attributes --output release_archive_audit_tag.json

Le tag et le commit sont maintenant présents sur origin. Le workflow de publication est suivi via GitHub Actions ; aucune publication manuelle avec un jeton n'est nécessaire.

Publication PyPI¶

Le workflow .github/workflows/publish-pypi.yml construit et vérifie les distributions avant publication. La publication est maintenant conditionnée à une release GitHub publiée ou à un tag Git v*; un lancement manuel sur une branche ne peut donc pas publier accidentellement un paquet.

L'environnement GitHub pypi doit contenir le secret PYPI_API_TOKEN. Le secret n'est jamais écrit dans le dépôt, le changelog, les artefacts ou les logs. Le compte PyPI et le projet qf-solver doivent être vérifiés par l'Owner avant le premier déclenchement.

Après publication, les contrôles externes sont :

python -m pip index versions qf-solver
python -m pip install --no-cache-dir "qf-solver==0.2.2a0"
qf-solver --version

Réserves à conserver dans la release¶

Le backend 0.2.2 alpha est validé dans un périmètre borné ; cela ne vaut pas une qualification générale de tous les modèles.
Le modal SLEPc à environ 2M DDL reste bloqué par la limite de ressources.
La tentative matrix-free à 1M DDL reste BLOCKED_TIMEOUT après 900 s.
Les scopes mécaniques non stables restent exclus de toute revendication stable et de toute extrapolation.
La publication PyPI ne doit pas être déduite du seul statut PASS des tests.

Décision de préparation¶

Le dossier technique et les métadonnées de distribution sont préparés. La release est gelée et taguée ; son état final dépend encore de la réussite du workflow de publication et de la confirmation de présence de 0.2.2a0 sur PyPI.