Passer au contenu principal

​
Prise en charge des versions pour les langages et les paquets

Chez AppSignal, nous avons une politique de support pour tous nos paquets d’intégration. Celle-ci définit quelle compatibilité nous maintenons avec les langages de programmation et les paquets avec lesquels nous nous intégrons. Nous pouvons abandonner la prise en charge de certaines versions de langages de programmation et de paquets au fil du temps. Consultez cette page pour notre politique. Cette politique peut être modifiée à l’avenir.

​
Raisonnement

Il existe de nombreuses versions de langages de programmation et de paquets. Nous ne pouvons pas raisonnablement tous les prendre en charge. Cela prendrait trop de temps à maintenir et limiterait notre travail à des syntaxes et fonctionnalités spécifiques des langages/paquets.

​
Langages de programmation

Nous prenons en charge les versions maintenues d’un langage de programmation avec lequel nous nous intégrons. Une fois qu’une version atteint sa fin de vie (EOL), nous abandonnons la prise en charge dans la prochaine version majeure ou mineure d’une intégration. Si possible, nous le faisons en mettant à jour l’exigence de version du langage dans nos définitions de paquets afin que l’installation échoue sur les versions plus anciennes. Consultez la politique de maintenance de chaque langage avec lequel nous nous intégrons ci-dessous. Si un langage que nous prenons en charge ne publie pas de politique de maintenance, nous déterminons la prise en charge au cas par cas en fonction des versions stables récentes et de ce que nous pouvons raisonnablement maintenir.
  • Politique de maintenance Ruby
  • Politique de maintenance Elixir
  • Politique de maintenance Node.js
    • Nous ne prenons en charge que les versions sous « Maintenance LTS », « Active LTS » et « Current ».
  • Politique de maintenance Python
    • Nous ne prenons en charge que les versions qui sont dans les états « feature », « bugfix » et « security ».
  • Politique de support JavaScript front-end.
    • Nous visons la compatibilité avec la plupart des navigateurs majeurs, jusqu’à Internet Explorer 9. Tous les navigateurs plus anciens que celui-ci ne peuvent être pris en charge qu’au mieux, et la pleine fonctionnalité ne peut être garantie.
    • Il prend également en charge différentes cibles :
      • Applications Electron
      • Processus à courte durée de vie
      • Fonctions serverless
      • Applications générées statiquement
      • Applications React Native/Expo

​
Paquets

Nous prenons en charge les versions maintenues d’un paquet avec lequel nous nous intégrons. Une fois qu’une version de paquet atteint sa fin de vie (EOL), nous abandonnons la prise en charge dans la prochaine version majeure ou mineure d’une intégration. Si possible, nous le faisons en mettant à jour l’exigence de version du paquet dans nos définitions de paquets ou d’une autre manière. Tous les paquets ne publient pas une politique de maintenance. Dans ces cas, nous déterminons la prise en charge au cas par cas en fonction des versions stables récentes et de ce que nous pouvons raisonnablement maintenir. Les versions plus anciennes des paquets peuvent continuer à fonctionner, mais nous ne garantissons ni le support ni les correctifs pour celles-ci.

​
Planifier une mise à niveau depuis une version antérieure

Les anciennes versions des paquets AppSignal peuvent encore s’installer et fonctionner, mais elles sont considérées comme legacy et peuvent dépendre de runtimes, de systèmes d’exploitation, de frameworks ou de paquets non pris en charge. Nous vous recommandons de mettre à niveau vers une version prise en charge, car nous ne prenons pas pleinement en charge les versions plus anciennes. Les tableaux Ruby et Elixir ci-dessous associent chaque plage de versions d’AppSignal à la version minimale du langage qu’elle requiert. Ils constituent une référence rapide — la source faisant autorité est la page de chaque paquet sur son registre, qui répertorie l’exigence pour chaque version.

​
Ruby

Le gemspec de 4.x autorise Ruby 2.7+, mais certaines installations sur Ruby 3.0 et versions antérieures peuvent encore échouer à cause du problème JSON::Fragment. La gem appsignal sur RubyGems indique la version de Ruby requise pour chaque version publiée. Pour effectuer une mise à niveau entre versions majeures de la gem, suivez le guide de mise à niveau de 2 vers 3 ou le guide de mise à niveau de 3 vers 4.

​
Elixir

La version Elixir minimale a changé à la version 2.0.0 du paquet. Le paquet appsignal sur Hex indique la version d’Elixir requise pour chaque version publiée. Pour passer à la dernière version du paquet, suivez le guide d’installation.

​
Node.js

Le paquet @appsignal/nodejs déclare sa version Node.js requise dans package.json. Pour effectuer une mise à niveau entre versions majeures, suivez le guide de migration 3.x.

​
Intégrations plus récentes

Pour les nouvelles intégrations (langages de programmation et paquets), cette politique de support ne s’applique pas. AppSignal ne ciblera d’abord que la version maintenue, ou la dernière version, d’un langage/paquet. Nous ne prendrons pas en charge les versions plus anciennes immédiatement, sauf si pertinent.

​
Branches Git

Pendant le processus de support, une application peut avoir testé un correctif ou une nouvelle fonctionnalité sur demande, en incluant l’une des intégrations AppSignal via Git par le biais d’une branche Git spécifique. Ces branches appartiennent à des Pull Requests qui sont finalement soit fusionnées, soit fermées. Ensuite, la branche qui appartient à la Pull Request est supprimée après six mois. Cela peut prendre plus de temps parfois, mais aucune garantie n’est donnée concernant la durée de vie des branches au-delà de ce point. Veuillez mettre à jour votre intégration vers la dernière version publiée des paquets dès que possible. Nous vous conseillons fortement de ne jamais déployer une application dans son environnement de production lorsqu’elle installe une intégration AppSignal via Git.