Versioning et rétrocompatibilité
Vavang Invoice suit Semantic Versioning pour les versions commerciales publiées, avec un contrat de notes de version explicite pour chaque release.
Numéros de version
Pour les versions stables (MAJOR.MINOR.PATCH) :
- PATCH : corrections de bugs, sécurité, compatibilité ou réglementation rétrocompatibles ;
- MINOR : fonctionnalités et extensions rétrocompatibles ;
- MAJOR : changements qui rompent intentionnellement le contrat public supporté.
Le plugin est encore préparé sur une ligne de développement pré-1.0 (dev-main est actuellement aliasé vers 0.1.x-dev). Le statut pré-1.0 ne supprime pas l’obligation de documenter les ruptures : chaque bêta/RC doit les déclarer explicitement.
Ce qui fait partie du contrat de compatibilité
La rétrocompatibilité couvre notamment :
- les plages PHP/Sylius/Sylius InvoicingPlugin supportées ;
- les clés de configuration publiques et leurs valeurs documentées ;
- les interfaces de services et points d’extension documentés ;
- les commandes et procédures opérationnelles documentées ;
- le schéma persistant et le chemin de migration ;
- les événements/hooks documentés utilisés par les intégrateurs ;
- les invariants d’historique de conformité et de transmission.
Les détails internes non documentés comme points d’extension ne constituent pas une promesse de BC publique.
Politique de dépréciation
Lorsque c’est possible, un contrat public qui doit être supprimé ou renommé est d’abord déprécié. La dépréciation doit indiquer le remplacement et l’horizon de suppression dans les notes de version/la documentation.
Une rupture immédiate peut néanmoins être imposée par un problème de sécurité, une obligation réglementaire ou une incompatibilité amont/prestataire. Dans ce cas, la release doit déclarer explicitement la rupture, l’action manuelle et les impacts migration/rollback ; elle ne doit jamais être livrée silencieusement comme un patch.
Compatibilité base de données
Une migration n’est pas considérée compatible rolling simplement parce que Doctrine sait l’exécuter. Chaque release déclare :
rolling-compatible— le nouveau schéma reste compatible avec la version applicative précédente pendant le déploiement ;maintenance required— une opération ne peut pas coexister de manière sûre avec la version précédente.
La déclaration propre à la release dans le changelog pilote le déploiement.
Règle pré-release
Les bêta/RC peuvent évoluer plus rapidement que les versions stables, mais les ruptures, changements de configuration, migrations et actions opérateur restent explicites. Une RC promue en stable doit disposer d’une entrée de changelog complète et de gates release/clean-install vertes.