Politique de maintenance et mises à jour
Un abonnement Vavang Invoice actif inclut les mises à jour correctives, de compatibilité et réglementaires publiées pendant la période d’entitlement pour les versions supportées.
Ce que comprend la maintenance
La maintenance publiée peut inclure :
- corrections de bugs et régressions ;
- corrections de sécurité ;
- évolutions de compatibilité pour les versions explicitement ajoutées à la matrice supportée ;
- corrections réglementaires/de conformité du comportement implémenté par le plugin ;
- maintenance des connecteurs pour les capacités explicitement supportées par la release ;
- migrations et instructions d’upgrade nécessaires à ces changements.
La maintenance ne garantit pas un support indéfini des versions PHP, Symfony, Sylius ou API prestataire en fin de vie.
Compatibilité des releases
Chaque release doit déclarer sa matrice supportée et sa compatibilité de migration. Une contrainte package n’est pas élargie tant que la nouvelle combinaison n’est pas couverte par la CI/le clean-install.
Les ruptures suivent la politique versioning/changelog et ne doivent jamais être cachées dans une release de maintenance ordinaire.
Période d’abonnement
L’entitlement standard dure 12 mois à partir de l’achat/renouvellement. Le renouvellement prolonge les droits de mise à jour/support de 12 mois et conserve les liaisons production existantes.
Après expiration :
- la version installée obtenue légalement pendant la période active peut continuer à fonctionner ;
- l’accès aux nouvelles versions commerciales et au support standard est indisponible jusqu’au renouvellement ;
- les nouvelles liaisons d’installations production sont indisponibles selon la politique standard jusqu’au renouvellement ;
- le traitement fiscal existant et son historique restent opérationnels.
Responsabilité de mise à jour
Vavang publie le package, les migrations, les informations de compatibilité et la procédure d’upgrade. Le marchand/intégrateur reste responsable de planifier et appliquer les releases dans l’application hôte : sauvegardes, gates de déploiement, redémarrage workers et tests de non-régression propres au projet.
Une mise à jour réglementaire peut être importante opérationnellement mais doit toujours être déployée et validée ; un abonnement actif ne modifie pas à distance l’application du marchand.
Fins de support
Lorsqu’une version de runtime/prestataire supportée doit être abandonnée, la documentation de release doit déclarer l’évolution de compatibilité. Lorsque c’est possible, une dépréciation/un guide de migration précède la suppression. Des contraintes de sécurité, réglementation ou fournisseur amont peuvent imposer un changement plus rapide ; il sera alors documenté explicitement.