Politique d'obsolescence
Aethex suit une politique d'obsolescence publique. Chaque changement pouvant affecter les intégrations existantes est annoncé sur le journal des changements avant son entrée en vigueur, avec une date de retrait et un chemin de migration.
Notre engagement
Les nouveaux endpoints, les nouveaux paramètres optionnels et les nouveaux champs dans les réponses existantes sont des ajouts rétrocompatibles et déployés sans préavis. Tout ce qui pourrait changer le comportement de code déjà écrit suit le calendrier décrit sur cette page. L'historique public de toutes les modifications est disponible dans le journal des changements.
Ce qui requiert une action
Un changement requiert une action si du code client qui fonctionnait hier échoue ou se comporte différemment après le changement. Exemples concrets : retrait d'un endpoint ou d'un champ, modification du type d'un champ, restriction des valeurs autorisées d'un paramètre, modification du code de statut sur succès, retrait d'un type d'événement webhook, ou passage d'un paramètre optionnel à requis.Un changement ne requiert pas d'action lorsqu'il ajoute un nouvel endpoint, ajoute un paramètre optionnel, ajoute un champ à une réponse, ajoute une valeur à un champ de chaîne ouvert, ou corrige un comportement documenté. Construisez votre intégration de manière à analyser les champs que vous connaissez et ignorer les champs inconnus ; de nouveaux champs apparaîtront avec le temps.
Préavis et calendrier
Chaque changement pouvant affecter les intégrations existantes est publié sur le journal des changements avant son entrée en vigueur. L'entrée nomme le changement, le chemin de migration et la date de retrait. Pendant la fenêtre de préavis, les requêtes vers la surface obsolète continuent de fonctionner. Après la date de retrait, le comportement précédent n'est plus garanti.Nous ne nous engageons pas sur un délai de préavis unique et fixe dans cette politique. La fenêtre adaptée dépend du changement : renommer un champ demande quelques jours, supprimer un endpoint entier demande plus de temps. Chaque entrée du journal indique le calendrier concret du changement. Les clients enterprise avec des exigences plus strictes peuvent négocier des fenêtres de préavis spécifiques via leur contrat.
Comment vous êtes informés
Le journal des changements est la source de vérité. Chaque changement requérant une action porte le tag Action requise avec la date de retrait et les étapes de migration. Consultez-le pour les nouvelles entrées avant toute mise à jour.Les notifications par e-mail, les en-têtes HTTP Deprecation / Sunset (RFC 8594) et les DeprecationWarning du SDK sont planifiés et seront disponibles avant la v1.0.0.